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Preface 


CMMI®  (Capability  Maturity  Model®  Integration)  models  are  collections  of 
best  practices  that  help  organizations  to  improve  their  processes.  These 
models  are  developed  by  product  teams  with  members  from  industry, 
government,  and  the  Software  Engineering  Institute  (SEI). 

This  model,  called  CMMI  for  Development  (CMMI-DEV),  provides  a 
comprehensive  integrated  set  of  guidelines  for  developing  products  and 
services. 


Purpose 


The  CMMI-DEV  model  provides  guidance  for  applying  CMMI  best  practices 
in  a  development  organization.  Best  practices  in  the  model  focus  on 
activities  for  developing  quality  products  and  services  to  meet  the  needs  of 
customers  and  end  users. 

The  CMMI-DEV,  V1 .3  model  is  a  collection  of  development  best  practices 
from  government  and  industry  that  is  generated  from  the  CMMI  V1 .3 
Architecture  and  Framework.^  CMMI-DEV  is  based  on  the  CMMI  Model 
Foundation  or  CMF  (i.e.,  model  components  common  to  all  CMMI  models 
and  constellations^)  and  incorporates  work  by  development  organizations  to 
adapt  CMMI  for  use  in  the  development  of  products  and  services. 
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constellation  recognizing  the  importance  of  providing  best  practices  to 
development  organizations. 


The  CMMI  Framework  is  the  basic  structure  that  organizes  CMMI  components  and  combines  them  into  CMMI  constellations 
and  models. 

A  constellation  is  a  collection  of  CMMI  components  that  are  used  to  construct  models,  training  materials,  and  appraisal  related 
documents  for  an  area  of  interest  (e.g.,  development,  acquisition,  services). 
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The  Product  Team  wrote,  reviewed,  revised,  discussed,  and  agreed  on  the 
structure  and  technical  content  of  the  CMMI  Product  Suite,  including  the 
framework,  models,  training,  and  appraisal  materials.  Development 
activities  were  based  on  multiple  inputs.  These  inputs  included  an  A- 
Specification  and  guidance  specific  to  each  release  provided  by  the 
Steering  Group,  source  models,  change  requests  received  from  the  user 
community,  and  input  received  from  pilots  and  other  stakeholders. 

The  CCB  is  the  official  mechanism  for  controlling  changes  to  CMMI  models, 
appraisal  related  documents,  and  Introduction  to  CMM  training.  As  such, 
this  group  ensures  integrity  over  the  life  of  the  product  suite  by  reviewing  all 
proposed  changes  to  the  baseline  and  approving  only  those  changes  that 
satisfy  identified  issues  and  meet  criteria  for  the  upcoming  release. 

Members  of  the  groups  involved  in  developing  CMMI-DEV,  V1 .3  are  listed 
in  Appendix  C. 


Audience 


The  audience  for  CMMI-DEV  includes  anyone  interested  in  process 
improvement  in  a  development  environment.  Whether  you  are  familiar  with 
the  concept  of  Capability  Maturity  Models  or  are  seeking  information  to 
begin  improving  your  development  processes,  CMMI-DEV  will  be  useful  to 
you.  This  model  is  also  intended  for  organizations  that  want  to  use  a 
reference  model  for  an  appraisal  of  their  development  related  processes.^ 


Organization  of  this  Document 


This  document  is  organized  into  three  main  parts: 

•  Part  One:  About  CMMI  for  Development 

•  Part  Two:  Generic  Goals  and  Generic  Practices,  and  the  Process  Areas 

•  Part  Three:  The  Appendices  and  Glossary 

Part  One:  About  CMMI  for  Development,  consists  of  five  chapters: 

•  Chapter  1 ,  Introduction,  offers  a  broad  view  of  CMMI  and  the  CMMI  for 
Development  constellation,  concepts  of  process  improvement,  and  the 
history  of  models  used  for  process  improvement  and  different  process 
improvement  approaches. 

•  Chapter  2,  Process  Area  Components,  describes  all  of  the  components 
of  the  CMMI  for  Development  process  areas. 

•  Chapter  3,  Tying  It  All  Together,  assembles  the  model  components  and 
explains  the  concepts  of  maturity  levels  and  capability  levels. 


An  appraisal  is  an  examination  of  one  or  more  processes  by  a  trained  team  of  professionals  using  a  reference  model  (e.g., 
CMMI-DEV)  as  the  basis  for  determining  strengths  and  weaknesses. 

A  process  area  is  a  cluster  of  related  practices  in  an  area  that,  when  implemented  collectively,  satisfies  a  set  of  goals 
considered  important  for  making  improvement  in  that  area.  This  concept  is  covered  in  detail  in  Chapter  2. 
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•  Chapter  4,  Relationships  Among  Process  Areas,  provides  insight  into 
the  meaning  and  interactions  among  the  CMMI-DEV  process  areas. 

•  Chapter  5,  Using  CMMI  Models,  describes  paths  to  adoption  and  the 
use  of  CMMI  for  process  improvement  and  benchmarking  of  practices 
in  a  development  organization. 

Part  Two:  Generic  Goals  and  Generic  Practices,  and  the  Process  Areas, 
contains  all  of  this  CMMI  model’s  required  and  expected  components.  It 
also  contains  related  informative  components,  including  subpractices, 
notes,  examples,  and  example  work  products. 

Part  Two  contains  23  sections.  The  first  section  contains  the  generic  goals 
and  practices.  The  remaining  22  sections  each  represent  one  of  the  CMMI- 
DEV  process  areas. 

To  make  these  process  areas  easy  to  find,  they  are  organized 
alphabetically  by  process  area  acronym.  Each  section  contains  descriptions 
of  goals,  best  practices,  and  examples. 

Part  Three:  The  Appendices  and  Glossary,  consists  of  four  sections: 

•  Appendix  A:  References,  contains  references  you  can  use  to  locate 
documented  sources  of  information  such  as  reports,  process 
improvement  models,  industry  standards,  and  books  that  are  related  to 
CMMI-DEV. 

•  Appendix  B:  Acronyms,  defines  the  acronyms  used  in  the  model. 

•  Appendix  C:  CMMI  Version  1 .3  Project  Participants  contains  lists  of 
team  members  who  participated  in  the  development  of  CMMI-DEV, 
V1.3. 

•  Appendix  D:  Glossary,  defines  many  of  the  terms  used  in  CMMI-DEV. 


How  to  Use  this  Document 


Whether  you  are  new  to  process  improvement,  new  to  CMMI,  or  already 
familiar  with  CMMI,  Part  One  can  help  you  understand  why  CMMI-DEV  is 
the  model  to  use  for  improving  your  development  processes. 

Readers  New  to  Process  Improvement 

If  you  are  new  to  process  improvement  or  new  to  the  Capability  Maturity 
Model  (CMM®)  concept,  we  suggest  that  you  read  Chapter  1  first.  Chapter  1 
contains  an  overview  of  process  improvement  that  explains  what  CMMI  is 
all  about. 

Next,  skim  Part  Two,  including  generic  goals  and  practices  and  specific 
goals  and  practices,  to  get  a  feel  for  the  scope  of  the  best  practices 
contained  in  the  model.  Pay  close  attention  to  the  purpose  and  introductory 
notes  at  the  beginning  of  each  process  area. 

In  Part  Three,  look  through  the  references  in  Appendix  A  and  select 
additional  sources  you  think  would  be  beneficial  to  read  before  moving 
forward  with  using  CMMI-DEV.  Read  through  the  acronyms  and  glossary  to 
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become  familiar  with  the  language  of  CMMI.  Then,  go  back  and  read  the 
details  of  Part  Two. 

Readers  Experienced  with  Process  improvement 

If  you  are  new  to  CMMI  but  have  experience  with  other  process 
improvement  models,  such  as  the  Software  CMM  or  the  Systems 
Engineering  Capability  Model  (i.e.,  EIA  731),  you  will  immediately  recognize 
many  similarities  in  their  structure  and  content  [EIA  2002a]. 

We  recommend  that  you  read  Part  One  to  understand  how  CMMI  is 
different  from  other  process  improvement  models.  If  you  have  experience 
with  other  models,  you  may  want  to  select  which  sections  to  read  first.  Read 
Part  Two  with  an  eye  for  best  practices  you  recognize  from  the  models  that 
you  have  already  used.  By  identifying  familiar  material,  you  will  gain  an 
understanding  of  what  is  new,  what  has  been  carried  over,  and  what  is 
familiar  from  the  models  you  already  know. 

Next,  review  the  glossary  to  understand  how  some  terminology  can  differ 
from  that  used  in  the  process  improvement  models  you  know.  Many 
concepts  are  repeated,  but  they  may  be  called  something  different. 

Readers  Familiar  with  CMMI 

If  you  have  reviewed  or  used  a  CMMI  model  before,  you  will  quickly 
recognize  the  CMMI  concepts  discussed  and  the  best  practices  presented. 
As  always,  the  improvements  that  the  CMMI  Product  Team  made  to  CMMI 
for  the  VI  .3  release  were  driven  by  user  input.  Change  requests  were 
carefully  considered,  analyzed,  and  implemented. 

Some  significant  improvements  you  can  expect  in  CMMI-DEV,  VI  .3  include 
the  following: 

•  High  maturity  process  areas  are  significantly  improved  to  reflect 
industry  best  practices,  including  a  new  specific  goal  and  several  new 
specific  practices  in  the  process  area  that  was  renamed  from 
Organizational  Innovation  and  Deployment  (OID)  to  Organizational 
Performance  Management  (0PM). 

•  Improvements  were  made  to  the  model  architecture  that  simplify  the 
use  of  multiple  models. 

•  Informative  material  was  improved,  including  revising  the  engineering 
practices  to  reflect  industry  best  practice  and  adding  guidance  for 
organizations  that  use  Agile  methods. 

•  Glossary  definitions  and  model  terminology  were  improved  to  enhance 
the  clarity,  accuracy,  and  usability  of  the  model. 

•  Level  4  and  5  generic  goals  and  practices  were  eliminated  as  well  as 
capability  levels  4  and  5  to  appropriately  focus  high  maturity  on  the 
achievement  of  business  objectives,  which  is  accomplished  by  applying 
capability  level  1-3  to  the  high  maturity  process  areas  (Causal  Analysis 
and  Resolution,  Quantitative  Project  Management,  Organizational 
Performance  Management,  and  Organizational  Process  Performance). 
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For  a  more  complete  and  detailed  list  of  improvements,  see 
http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/. 


Additional  Information  and  Reader  Feedback 


Many  sources  of  information  about  CMMI  are  listed  in  Appendix  A  and  are 
also  published  on  the  CMMI  website — http://www.sei.cmu.edu/cmmi/. 

Your  suggestions  for  improving  CMMI  are  welcome.  For  information  on  how 
to  provide  feedback,  see  the  CMMI  website  at 

http://www.sei.cmu.edu/cmmi/tools/cr/.  If  you  have  questions  about  CMMI, 
send  email  to  cmmi-comments@sei.cmu.edu. 
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1  Introduction 


Now  more  than  ever,  companies  want  to  deliver  products  and  services 
better,  faster,  and  cheaper.  At  the  same  time,  in  the  high-technology 
environment  of  the  twenty-first  century,  nearly  all  organizations  have  found 
themselves  building  increasingly  complex  products  and  services.  It  is 
unusual  today  for  a  single  organization  to  develop  all  the  components  that 
compose  a  complex  product  or  service.  More  commonly,  some  components 
are  built  in-house  and  some  are  acquired;  then  all  the  components  are 
integrated  into  the  final  product  or  service.  Organizations  must  be  able  to 
manage  and  control  this  complex  development  and  maintenance  process. 

The  problems  these  organizations  address  today  involve  enterprise-wide 
solutions  that  require  an  integrated  approach.  Effective  management  of 
organizational  assets  is  critical  to  business  success.  In  essence,  these 
organizations  are  product  and  service  developers  that  need  a  way  to 
manage  their  development  activities  as  part  of  achieving  their  business 
objectives. 

In  the  current  marketplace,  maturity  models,  standards,  methodologies,  and 
guidelines  exist  that  can  help  an  organization  improve  the  way  it  does 
business.  However,  most  available  improvement  approaches  focus  on  a 
specific  part  of  the  business  and  do  not  take  a  systemic  approach  to  the 
problems  that  most  organizations  are  facing.  By  focusing  on  improving  one 
area  of  a  business,  these  models  have  unfortunately  perpetuated  the 
stovepipes  and  barriers  that  exist  in  organizations. 

CMMI®  for  Development  (CMMI-DEV)  provides  an  opportunity  to  avoid  or 
eliminate  these  stovepipes  and  barriers.  CMMI  for  Development  consists  of 
best  practices  that  address  development  activities  applied  to  products  and 
services.  It  addresses  practices  that  cover  the  product’s  lifecycle  from 
conception  through  delivery  and  maintenance.  The  emphasis  is  on  the  work 
necessary  to  build  and  maintain  the  total  product. 

CMMI-DEV  contains  22  process  areas.  Of  those  process  areas,  16  are  core 
process  areas,  1  is  a  shared  process  area,  and  5  are  development  specific 
process  areas. ^ 

All  CMMI-DEV  model  practices  focus  on  the  activities  of  the  developer 
organization.  Five  process  areas  focus  on  practices  specific  to 
development:  addressing  requirements  development,  technical  solution, 
product  integration,  verification,  and  validation. 


A  core  process  area  is  a  process  area  that  is  common  to  all  CMMI  models.  A  shared  process  area  is  shared  by  at  least  two 
CMMI  models,  but  not  all  of  them. 
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About  Process  Improvement 


In  its  research  to  help  organizations  to  develop  and  maintain  quality 
products  and  services,  the  Software  Engineering  Institute  (SEI)  has  found 
several  dimensions  that  an  organization  can  focus  on  to  improve  its 
business.  Figure  1 .1  illustrates  the  three  critical  dimensions  that 
organizations  typically  focus  on:  people,  procedures  and  methods,  and 
tools  and  equipment. 

Procedures  and  methods 
defining  the  relationship  of 
tasks 


Figure  1.1:  The  Three  Critical  Dimensions 

What  holds  everything  together?  It  is  the  processes  used  in  your 
organization.  Processes  allow  you  to  align  the  way  you  do  business.  They 
allow  you  to  address  scalability  and  provide  a  way  to  incorporate  knowledge 
of  how  to  do  things  better.  Processes  allow  you  to  leverage  your  resources 
and  to  examine  business  trends. 

This  is  not  to  say  that  people  and  technology  are  not  important.  We  are 
living  in  a  world  where  technology  is  changing  at  an  incredible  speed. 
Similarly,  people  typically  work  for  many  companies  throughout  their 
careers.  We  live  in  a  dynamic  world.  A  focus  on  process  provides  the 
infrastructure  and  stability  necessary  to  deal  with  an  ever-changing  world 
and  to  maximize  the  productivity  of  people  and  the  use  of  technology  to  be 
competitive. 

Manufacturing  has  long  recognized  the  importance  of  process  effectiveness 
and  efficiency.  Today,  many  organizations  in  manufacturing  and  service 
industries  recognize  the  importance  of  quality  processes.  Process  helps  an 
organization’s  workforce  to  meet  business  objectives  by  helping  them  to 
work  smarter,  not  harder,  and  with  improved  consistency.  Effective 
processes  also  provide  a  vehicle  for  introducing  and  using  new  technology 
in  a  way  that  best  meets  the  business  objectives  of  the  organization. 


4 


Introduction 


CMMI  for  Development,  Version  1.3 


About  Capability  Maturity  Models 

A  Capability  Maturity  Model®  (CMM®),  including  CMMI,  is  a  simplified 
representation  of  the  world.  CMMs  contain  the  essential  elements  of 
effective  processes.  These  elements  are  based  on  the  concepts  developed 
by  Crosby,  Deming,  Juran,  and  Humphrey. 

In  the  1930s,  Walter  Shewhart  began  work  in  process  improvement  with  his 
principles  of  statistical  quality  control  [Shewhart  1931].  These  principles 
were  refined  by  W.  Edwards  Deming  [Deming  1986],  Phillip  Crosby  [Crosby 
1979],  and  Joseph  Juran  [Juran  1988].  Watts  Humphrey,  Ron  Radice,  and 
others  extended  these  principles  further  and  began  applying  them  to 
software  in  their  work  at  IBM  (International  Business  Machines)  and  the  SEI 
[Humphrey  1989].  Humphrey’s  book,  Managing  the  Software  Process, 
provides  a  description  of  the  basic  principles  and  concepts  on  which  many 
of  the  Capability  Maturity  Models®  (CMMs®)  are  based. 

The  SEI  has  taken  the  process  management  premise,  “the  quality  of  a 
system  or  product  is  highly  influenced  by  the  quality  of  the  process  used  to 
develop  and  maintain  it,”  and  defined  CMMs  that  embody  this  premise.  The 
belief  in  this  premise  is  seen  worldwide  in  quality  movements,  as  evidenced 
by  the  International  Organization  for  Standardization/International 
Electrotechnical  Commission  (ISO/IEC)  body  of  standards. 

CMMs  focus  on  improving  processes  in  an  organization.  They  contain  the 
essential  elements  of  effective  processes  for  one  or  more  disciplines  and 
describe  an  evolutionary  improvement  path  from  ad  hoc,  immature 
processes  to  disciplined,  mature  processes  with  improved  quality  and 
effectiveness. 

Like  other  CMMs,  CMMI  models  provide  guidance  to  use  when  developing 
processes.  CMMI  models  are  not  processes  or  process  descriptions.  The 
actual  processes  used  in  an  organization  depend  on  many  factors, 
including  application  domains  and  organization  structure  and  size.  In 
particular,  the  process  areas  of  a  CMMI  model  typically  do  not  map  one  to 
one  with  the  processes  used  in  your  organization. 

The  SEI  created  the  first  CMM  designed  for  software  organizations  and 
published  it  in  a  book.  The  Capability  Maturity  Model:  Guidelines  for 
Improving  the  Software  Process  [SE1 1995]. 

Today,  CMMI  is  an  application  of  the  principles  introduced  almost  a  century 
ago  to  this  never-ending  cycle  of  process  improvement.  The  value  of  this 
process  improvement  approach  has  been  confirmed  over  time. 
Organizations  have  experienced  increased  productivity  and  quality, 
improved  cycle  time,  and  more  accurate  and  predictable  schedules  and 
budgets  [Gibson  2006]. 


Evolution  of  CMMI 

The  CMM  Integration®  pro]ect  was  formed  to  sort  out  the  problem  of  using 
multiple  CMMs.  The  combination  of  selected  models  into  a  single 
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improvement  framework  was  intended  for  use  by  organizations  in  their 
pursuit  of  enterprise-wide  process  improvement. 

Developing  a  set  of  integrated  models  involved  more  than  simply  combining 
existing  model  materials.  Using  processes  that  promote  consensus,  the 
CMMI  Product  Team  built  a  framework  that  accommodates  multiple 
constellations. 

The  first  model  to  be  developed  was  the  CMMI  for  Development  model 
(then  simply  called  “CMMI”).  Figure  1.2  illustrates  the  models  that  led  to 
CMMI  Version  1 .3. 


History  of  CMMs 


CMM  for  Software 
VI. 1 


Software  Acquisition 
CMM  VI  .03  (2002) 


1 

\ 

f 

INCOSI 

(1996) 

=  SECAM 

Software  CMI 
V2,  draft  C  (1 

I/I 

997) 

f 

Systems  Engineering 
CMM  VI  .1  (1995) 


EIA  7: 
(1998 

n  SECM 

> 

/ 

CMMI  for  Acquisition 
VI  .2  (2007)  


VI  .02  (2000) 


VI  .1  (2002) 


CMMI  for  Development 
VI  .2  (2006) 


Integrated  Product 
Development  CMM 
(1997) 


CMMI  for  Services 
VI  .2  (2009) 


I 


CMMI  for  Acquisition 
VI  .3  (2010) 


CMMI  for  Development 
VI  .3  (2010) 


CMMI  for  Services 
VI  .3  (2010) 


Figure  1.2:  The  History  of  CMMs® 


Initially,  CMMI  was  one  model  that  combined  three  source  models:  the 
Capability  Maturity  Model  for  Software  (SW-CMM)  v2.0  draft  C,  the 
Systems  Engineering  Capability  Model  {SECM)  [EIA  2002a],  and  the 
Integrated  Product  Development  Capability  Maturity  Model  (IPD-CMM) 
vO.98. 


ElA  731  SECM  is  the  Electronic  Industries  Alliance  standard  731 ,  or  the  Systems  Engineering  Capability  Model.  INCOSE 
SECAM  is  International  Council  on  Systems  Engineering  Systems  Engineering  Capability  Assessment  Model  [EIA  2002a]. 
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These  three  source  models  were  selected  because  of  their  successful 
adoption  or  promising  approach  to  improving  processes  in  an  organization. 

The  first  CMMI  model  (V1 .02)  was  designed  for  use  by  development 
organizations  in  their  pursuit  of  enterprise-wide  process  improvement.  It 
was  released  in  2000.  Two  years  later  version  1 .1  was  released  and  four 
years  after  that,  version  1 .2  was  released. 

By  the  time  that  version  1 .2  was  released,  two  other  CMMI  models  were 
being  planned.  Because  of  this  planned  expansion,  the  name  of  the  first 
CMMI  model  had  to  change  to  become  CMMI  for  Development  and  the 
concept  of  constellations  was  created. 

The  CMMI  for  Acquisition  model  was  released  in  2007.  Since  it  built  on  the 
CMMI  for  Development  Version  1 .2  model,  it  also  was  named  Version  1 .2. 
Two  years  later  the  CMMI  for  Services  model  was  released.  It  built  on  the 
other  two  models  and  also  was  named  Version  1 .2. 

In  2008  plans  were  drawn  to  begin  developing  Version  1 .3,  which  would 
ensure  consistency  among  all  three  models  and  improve  high  maturity 
material  in  all  of  the  models.  Version  1 .3  of  CMMI  for  Acquisition  [Gallagher 
201 1 ,  SEI  201  Ob],  CMMI  for  Development  [Chrissis  201 1  ],  and  CMMI  for 
Services  [Forrester  201 1 ,  SEI  201  Oa]  were  released  in  November  201 0. 


CMMI  Framework 


The  CMMI  Framework  provides  the  structure  needed  to  produce  CMMI 
models,  training,  and  appraisal  components.  To  allow  the  use  of  multiple 
models  within  the  CMMI  Framework,  model  components  are  classified  as 
either  common  to  all  CMMI  models  or  applicable  to  a  specific  model.  The 
common  material  is  called  the  “CMMI  Model  Foundation”  or  “CMF.” 

The  components  of  the  CMF  are  part  of  every  model  generated  from  the 
CMMI  Framework.  Those  components  are  combined  with  material 
applicable  to  an  area  of  interest  (e.g.,  acquisition,  development,  services)  to 
produce  a  model. 

A  “constellation”  is  defined  as  a  collection  of  CMMI  components  that  are 
used  to  construct  models,  training  materials,  and  appraisal  related 
documents  for  an  area  of  interest  (e.g.,  acquisition,  development,  services). 
The  Development  constellation’s  model  is  called  “CMMI  for  Development” 
or  “CMMI-DEV.” 


CMMI  for  Development 


CMMI  for  Development  is  a  reference  model  that  covers  activities  for 
developing  both  products  and  services.  Organizations  from  many 
industries,  including  aerospace,  banking,  computer  hardware,  software, 
defense,  automobile  manufacturing,  and  telecommunications,  use  CMMI  for 
Development. 
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CMMI  for  Development  contains  practices  that  cover  project  management, 
process  management,  systems  engineering,  hardware  engineering, 
software  engineering,  and  other  supporting  processes  used  in  development 
and  maintenance. 

Use  professional  judgment  and  common  sense  to  interpret  the  model  for 
your  organization.  That  is,  although  the  process  areas  described  in  this 
model  depict  behaviors  considered  best  practices  for  most  users,  process 
areas  and  practices  should  be  interpreted  using  an  in-depth  knowledge  of 
CMMI-DEV,  your  organizational  constraints,  and  your  business 
environment. 
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2  Process  Area  Components 


This  chapter  describes  the  components  found  in  each  process  area  and  in 
the  generic  goals  and  generic  practices.  Understanding  these  components 
is  critical  to  using  the  information  in  Part  Two  effectively.  If  you  are 
unfamiliar  with  Part  Two,  you  may  want  to  skim  the  Generic  Goals  and 
Generic  Practices  section  and  a  couple  of  process  area  sections  to  get  a 
general  feel  for  the  content  and  layout  before  reading  this  chapter. 


Core  Process  Areas  and  CMMI  Models 


All  CMMI  models  are  produced  from  the  CMMI  Framework.  This  framework 
contains  all  of  the  goals  and  practices  that  are  used  to  produce  CMMI 
models  that  belong  to  CMMI  constellations. 

All  CMMI  models  contain  16  core  process  areas.  These  process  areas 
cover  basic  concepts  that  are  fundamental  to  process  improvement  in  any 
area  of  interest  (i.e.,  acquisition,  development,  services).  Some  of  the 
material  in  the  core  process  areas  is  the  same  in  all  constellations.  Other 
material  may  be  adjusted  to  address  a  specific  area  of  interest. 
Consequently,  the  material  in  the  core  process  areas  may  not  be  exactly 
the  same. 


Required,  Expected,  and  Informative  Components 


Model  components  are  grouped  into  three  categories — required,  expected, 
and  informative — that  reflect  how  to  interpret  them. 

Required  Components _ 

Required  components  are  CMMI  components  that  are  essential  to 
achieving  process  improvement  in  a  given  process  area.  This  achievement 
must  be  visibly  implemented  in  an  organization’s  processes.  The  required 
components  in  CMMI  are  the  specific  and  generic  goals.  Goal  satisfaction  is 
used  in  appraisals  as  the  basis  for  deciding  whether  a  process  area  has 
been  satisfied. 

Expected  Components _ 

Expected  components  are  CMMI  components  that  describe  the  activities 
that  are  important  in  achieving  a  required  CMMI  component.  Expected 
components  guide  those  who  implement  improvements  or  perform 
appraisals.  The  expected  components  in  CMMI  are  the  specific  and  generic 
practices. 


Process  Area  Components 


9 


CMMI  for  Development,  Version  1.3 


Before  goals  can  be  considered  to  be  satisfied,  either  their  practices  as 
described,  or  acceptable  alternatives  to  them,  must  be  present  in  the 
planned  and  implemented  processes  of  the  organization. 

Informative  Components 

Informative  components  are  CMMI  components  that  help  model  users 
understand  CMMI  required  and  expected  components.  These  components 
can  be  example  boxes,  detailed  explanations,  or  other  helpful  information. 
Subpractices,  notes,  references,  goal  titles,  practice  titles,  sources, 
example  work  products,  and  generic  practice  elaborations  are  informative 
model  components. 

The  informative  material  plays  an  important  role  in  understanding  the 
model.  It  is  often  impossible  to  adequately  describe  the  behavior  required  or 
expected  of  an  organization  using  only  a  single  goal  or  practice  statement. 
The  model’s  informative  material  provides  information  necessary  to  achieve 
the  correct  understanding  of  goals  and  practices  and  thus  cannot  be 
ignored. 


Components  Associated  with  Part  Two 


The  model  components  associated  with  Part  Two  are  summarized  in  Figure 
2.1  to  illustrate  their  relationships. 


Figure  2.1:  CMMI  Model  Components 

The  following  sections  provide  detailed  descriptions  of  CMMI  model 
components. 
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Process  Areas _ 

A  process  area  is  a  cluster  of  related  practices  in  an  area  that,  when 
implemented  collectively,  satisfies  a  set  of  goals  considered  important  for 
making  improvement  in  that  area.  (See  the  definition  of  “process  area”  in 
the  glossary.) 

The  22  process  areas  are  presented  in  alphabetical  order  by  acronym: 

•  Causal  Analysis  and  Resolution  (CAR) 

•  Configuration  Management  (CM) 

•  Decision  Analysis  and  Resolution  (DAR) 

•  Integrated  Project  Management  (IPM) 

•  Measurement  and  Analysis  (MA) 

•  Organizational  Process  Definition  (OPD) 

•  Organizational  Process  Focus  (OPF) 

•  Organizational  Performance  Management  (0PM) 

•  Organizational  Process  Performance  (OPP) 

•  Organizational  Training  (OT) 

•  Product  Integration  (PI) 

•  Project  Monitoring  and  Control  (PMC) 

•  Project  Planning  (PP) 

•  Process  and  Product  Ouality  Assurance  (PPOA) 

•  Ouantitative  Project  Management  (0PM) 

•  Requirements  Development  (RD) 

•  Requirements  Management  (REOM) 

•  Risk  Management  (RSKM) 

•  Supplier  Agreement  Management  (SAM) 

•  Technical  Solution  (TS) 

•  Validation  (VAL) 

•  Verification  (VER) 

Purpose  Statements _ 

A  purpose  statement  describes  the  purpose  of  the  process  area  and  is  an 
informative  component. 

For  example,  the  purpose  statement  of  the  Organizational  Process 
Definition  process  area  is  “The  purpose  of  Organizational  Process 
Definition  (OPD)  is  to  establish  and  maintain  a  usable  set  of  organizational 
process  assets,  work  environment  standards,  and  rules  and  guidelines  for 
teams.” 

Introductory  Notes _ 

The  introductory  notes  section  of  the  process  area  describes  the  major 
concepts  covered  in  the  process  area  and  is  an  informative  component. 
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An  example  from  the  introductory  notes  of  the  Project  Monitoring  and 
Control  process  area  is  “When  actual  status  deviates  significantly  from 
expected  values,  corrective  actions  are  taken  as  appropriate.” 

Related  Process  Areas _ 

The  Related  Process  Areas  section  lists  references  to  related  process 
areas  and  reflects  the  high-level  relationships  among  the  process  areas. 

The  Related  Process  Areas  section  is  an  informative  component. 

An  example  of  a  reference  found  in  the  Related  Process  Areas  section  of 
the  Project  Planning  process  area  is  “Refer  to  the  Risk  Management 
process  area  for  more  information  about  identifying  and  analyzing  risks  and 
mitigating  risks.” 

Specific  Goals _ 

A  specific  goal  describes  the  unique  characteristics  that  must  be  present  to 
satisfy  the  process  area.  A  specific  goal  is  a  required  model  component  and 
is  used  in  appraisals  to  help  determine  whether  a  process  area  is  satisfied. 
(See  the  definition  of  “specific  goal”  in  the  glossary.) 

For  example,  a  specific  goal  from  the  Configuration  Management  process 
area  is  “Integrity  of  baselines  is  established  and  maintained.” 

Only  the  statement  of  the  specific  goal  is  a  required  model  component.  The 
title  of  a  specific  goal  (preceded  by  the  goal  number)  and  notes  associated 
with  the  goal  are  considered  informative  model  components. 

Generic  Goals _ 

Generic  goals  are  called  “generic”  because  the  same  goal  statement 
applies  to  multiple  process  areas.  A  generic  goal  describes  the 
characteristics  that  must  be  present  to  institutionalize  processes  that 
implement  a  process  area.  A  generic  goal  is  a  required  model  component 
and  is  used  in  appraisals  to  determine  whether  a  process  area  is  satisfied. 
(See  the  Generic  Goals  and  Generic  Practices  section  in  Part  Two  for  a 
more  detailed  description  of  generic  goals.  See  the  definition  of  “generic 
goal”  in  the  glossary.) 

An  example  of  a  generic  goal  is  “The  process  is  institutionalized  as  a 
defined  process.” 

Only  the  statement  of  the  generic  goal  is  a  required  model  component.  The 
title  of  a  generic  goal  (preceded  by  the  goal  number)  and  notes  associated 
with  the  goal  are  considered  informative  model  components. 

Specific  Goai  and  Practice  Summaries 

The  specific  goal  and  practice  summary  provides  a  high-level  summary  of 
the  specific  goals  and  specific  practices.  The  specific  goal  and  practice 
summary  is  an  informative  component. 
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Specific  Practices _ 

A  specific  practice  is  the  description  of  an  activity  that  is  considered 
important  in  achieving  the  associated  specific  goal.  The  specific  practices 
describe  the  activities  that  are  expected  to  result  in  achievement  of  the 
specific  goals  of  a  process  area.  A  specific  practice  is  an  expected  model 
component.  (See  the  definition  of  “specific  practice”  in  the  glossary.) 

For  example,  a  specific  practice  from  the  Project  Monitoring  and  Control 
process  area  is  “Monitor  commitments  against  those  identified  in  the  project 
plan.” 

Only  the  statement  of  the  specific  practice  is  an  expected  model 
component.  The  title  of  a  specific  practice  (preceded  by  the  practice 
number)  and  notes  associated  with  the  specific  practice  are  considered 
informative  model  components. 

Example  Work  Products 

The  example  work  products  section  lists  sample  outputs  from  a  specific 
practice.  An  example  work  product  is  an  informative  model  component. 

(See  the  definition  of  “example  work  product”  in  the  glossary.) 

For  instance,  an  example  work  product  for  the  specific  practice  “Monitor 
Project  Planning  Parameters”  in  the  Project  Monitoring  and  Control  process 
area  is  “Records  of  significant  deviations.” 

Subpractices _ 

A  subpractice  is  a  detailed  description  that  provides  guidance  for 
interpreting  and  implementing  a  specific  or  generic  practice.  Subpractices 
can  be  worded  as  if  prescriptive,  but  they  are  actually  an  informative 
component  meant  only  to  provide  ideas  that  may  be  useful  for  process 
improvement.  (See  the  definition  of  “subpractice”  in  the  glossary.) 

For  example,  a  subpractice  for  the  specific  practice  “Take  Corrective 
Action”  in  the  Project  Monitoring  and  Control  process  area  is  “Determine 
and  document  the  appropriate  actions  needed  to  address  identified  issues.” 

Generic  Practices _ 

Generic  practices  are  called  “generic”  because  the  same  practice  applies  to 
multiple  process  areas.  The  generic  practices  associated  with  a  generic 
goal  describe  the  activities  that  are  considered  important  in  achieving  the 
generic  goal  and  contribute  to  the  institutionalization  of  the  processes 
associated  with  a  process  area.  A  generic  practice  is  an  expected  model 
component.  (See  the  definition  of  “generic  practice”  in  the  glossary.) 

For  example,  a  generic  practice  for  the  generic  goal  “The  process  is 
institutionalized  as  a  managed  process”  is  “Provide  adequate  resources  for 
performing  the  process,  developing  the  work  products,  and  providing  the 
services  of  the  process.” 

Only  the  statement  of  the  generic  practice  is  an  expected  model 
component.  The  title  of  a  generic  practice  (preceded  by  the  practice 
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number)  and  notes  associated  with  the  practice  are  considered  informative 
model  components. 

Generic  Practice  Eiaborations 

Generic  practice  elaborations  appear  after  generic  practices  to  provide 
guidance  on  how  the  generic  practices  can  be  applied  uniquely  to  process 
areas.  A  generic  practice  elaboration  is  an  informative  model  component. 
(See  the  definition  of  “generic  practice  elaboration”  in  the  glossary.) 

For  example,  a  generic  practice  elaboration  after  the  generic  practice 
“Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  process”  for  the  Project  Planning  process  area  is  “This 
policy  establishes  organizational  expectations  for  estimating  the  planning 
parameters,  making  internal  and  external  commitments,  and  developing  the 
plan  for  managing  the  project.” 

Additions 

Additions  are  clearly  marked  model  components  that  contain  information  of 
interest  to  particular  users.  An  addition  can  be  informative  material,  a 
specific  practice,  a  specific  goal,  or  an  entire  process  area  that  extends  the 
scope  of  a  model  or  emphasizes  a  particular  aspect  of  its  use.  There  are  no 
additions  in  the  CMMI-DEV  model. 


Supporting  Informative  Components 


In  many  places  in  the  model,  further  information  is  needed  to  describe  a 
concept.  This  informative  material  is  provided  in  the  form  of  the  following 
components: 

•  Notes 

•  Examples 

•  References 

Notes _ 

A  note  is  text  that  can  accompany  nearly  any  other  model  component.  It 
may  provide  detail,  background,  or  rationale.  A  note  is  an  informative  model 
component. 

For  example,  a  note  that  accompanies  the  specific  practice  “Implement 
Action  Proposals”  in  the  Causal  Analysis  and  Resolution  process  area  is 
“Only  changes  that  prove  to  be  of  value  should  be  considered  for  broad 
implementation.” 

Examples 

An  example  is  a  component  comprising  text  and  often  a  list  of  items,  usually 
in  a  box,  that  can  accompany  nearly  any  other  component  and  provides 
one  or  more  examples  to  clarify  a  concept  or  described  activity.  An  example 
is  an  informative  model  component. 
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The  following  is  an  example  that  accompanies  the  subpractice  “Document 
noncompliance  issues  when  they  cannot  be  resolved  in  the  project”  under 
the  specific  practice  “Communicate  and  Ensure  the  Resolution  of 
Noncompliance  Issues”  in  the  Process  and  Product  Quality  Assurance 
process  area. 

Examples  of  ways  to  resolve  noncompliance  in  the  project  include  the  following: 

•  Fixing  the  noncompliance 

•  Changing  the  process  descriptions,  standards,  or  procedures  that  were  violated 

•  Obtaining  a  waiver  to  cover  the  noncompliance 


References 

A  reference  is  a  pointer  to  additional  or  more  detailed  information  in  related 
process  areas  and  can  accompany  nearly  any  other  model  component.  A 
reference  is  an  informative  model  component.  (See  the  definition  of 
“reference”  in  the  glossary.) 

For  example,  a  reference  that  accompanies  the  specific  practice  “Compose 
the  Defined  Process”  in  the  Quantitative  Project  Management  process  area 
is  “Refer  to  the  Qrganizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets.” 


Numbering  Scheme 


Specific  and  generic  goals  are  numbered  sequentially.  Each  specific  goal 
begins  with  the  prefix  “SG”  (e.g.,  SG  1).  Each  generic  goal  begins  with  the 
prefix  “GG”  (e.g.,  GG  2). 

Specific  and  generic  practices  are  also  numbered  sequentially.  Each 
specific  practice  begins  with  the  prefix  “SP,”  followed  by  a  number  in  the 
form  “x.y”  (e.g.,  SP  1.1).  The  x  is  the  same  number  as  the  goal  to  which  the 
specific  practice  maps.  The  y  is  the  sequence  number  of  the  specific 
practice  under  the  specific  goal. 

An  example  of  specific  practice  numbering  is  in  the  Project  Planning 
process  area.  The  first  specific  practice  is  numbered  SP  1 .1  and  the  second 
is  SP  1.2. 

Each  generic  practice  begins  with  the  prefix  “GP,”  followed  by  a  number  in 
the  form  “x.y”  (e.g.,  GP  1.1). 

The  X  corresponds  to  the  number  of  the  generic  goal.  The  y  is  the  sequence 
number  of  the  generic  practice  under  the  generic  goal.  For  example,  the 
first  generic  practice  associated  with  GG  2  is  numbered  GP  2.1  and  the 
second  is  GP  2.2. 
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Typographical  Conventions 


The  typographical  conventions  used  in  this  model  were  designed  to  enable 
you  to  easily  identify  and  select  model  components  by  presenting  them  in 
formats  that  allow  you  to  find  them  quickly  on  the  page. 

Figures  2.2,  2.3,  and  2.4  are  sample  pages  from  process  areas  in  Part  Two; 
they  show  the  different  process  area  components,  labeled  so  that  you  can 
identify  them.  Notice  that  components  differ  typographically  so  that  you  can 
easily  identify  each  one. 
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Process  Area  Name 


DECISION  ANALYSIS  AND  RESOLUTION 


Introductory  Notes 


The  purpose  of  Decision  Analysis  and  Resolution  (DAR)  is  to  analyze 
possible  decisions  using  a  formal  evaluation  process  that  evaluates 
identified  alternatives  against  established  criteria. 


Purpose  Statement 


The  Decision  Analysis  and  Resolution  process  area  involves  establishing 
guidelines  to  determine  which  issues  should  be  subject  to  a  formal 
evaluation  process  and  applying  formal  evaluatbn  processes  to  these 
issues. 

A  formal  evaluation  process  is  a  stmctured  approach  to  evaluating 
alternative  solutions  against  established  criteria  to  determine  a 
recommended  solution. 


Introductory  Notes 


A  formal  evaluation  process  involves  the  following  actions: 

•  Establishing  the  criteria  for  evaluating  alternatives 

•  Identifying  alternative  solutions 

•  Selecting  methods  for  evaluating  alternatives 

•  Evaluating  alternative  solutions  using  established  criteria  and  methods 

•  Selecting  recommended  solutions  from  alternatives  based  on 
evaluation  criteria 


Ratherthan  using  the  phrase  'alternative  solutions  to  address  issues'  each 
time,  in  this  process  area,  one  of  two  shorter  phrases  are  used:  ‘alternative 
solutions*  or ‘alternatives  ' 

A  formal  evaluation  process  reduces  the  subjective  nature  of  a  decision  and 
provides  a  higher  probability  of  selecting  a  solution  that  meets  multiple 
demands  of  relevant  stakeholders 

While  the  primary  application  of  this  process  area  is  to  technical  concerns, 
formal  evaluation  processes  can  be  applied  to  many  nontechnical  issues, 
particularly  when  a  project  is  being  planned.  Issues  that  have  multiple 
alternative  solutions  and  evaluation  criteria  lend  themselves  to  a  formal 
evaluation  process. 

;  Tradestudiesotequipmentorsoftwarearetypcalexamplesoffornialevaluatlonprooesses.  | 


During  planning,  specific  issues  requiring  a  formal  evaluation  process  are 
identified  Typical  issues  include  selection  among  architectural  or  design 
alternatives,  use  of  reusable  or  commercial  off-the-shelf  (COTS) 
components,  supplier  selection,  engineering  support  environments  or 
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SG  2  Address  Causes  of  Selected  Outcomes 

Root  causes  of  selected  outcomes  are  systematically  addressed. 


Specific  Goai 


Projects  operating  according  to  a  well-defined  process  systematically 
analyze  where  improvements  are  needed  and  implement  process  changes 
to  address  root  causes  of  selected  outcomes. 


SP2.1 


Specific  Practice 


Exampie  Work  Product 


Implement  Action  Proposals 

Implement  seiected  action  proposals  developed  in  causal  analysis. 

Action  proposals  describe  tasks  necessary  to  address  root  causes  of 
analyzed  outcomes  to  prevent  or  reduce  the  occurrence  or  recurrence  of 
negative  outcomes,  or  incorporate  realized  successes.  Action  plans  are 
developed  and  implemented  for  selected  action  proposals.  Only  changes 
that  proveto  be  of  value  should  be  considered  for  broad  implementation 

Example  Work  Products 

1 .  Action  proposals  selected  for  implementation 

2.  Action  plans 


Exampie  Box 


Subpractices 

1 .  Analyze  action  proposals  and  determine  their  priorities. 
I  Criteria  for  priofitizing  action  proposals  Include  the  folowing: 

I 

I  •  Indications  of  not  addressng  the  outome 
I  •  Costto»TiplernentprocessiTiproverT«ntstoadd»es5theoutoonie 

I 

;•  Expected  inpact  on  quakty 


Process  performance  models  can  be  used  to  help  identify  interactions  among  multiple 
action  proposals. 

2  Select  action  proposals  to  be  implemented. 


3. 


Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  analyzing  possible  decisions  using  a  formal 
evaluation  process  that  evaluates  identified  alternatives  against 
established  catena. 

Create  action  plans  for  implementing  the  selected  action  proposals. 


132  Causal  Analysis  and  Resolution  (CAR) 
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GG2 


Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP2.1 


Establish  an  Organizational  Policy 


Generic  Practice 


Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  process. 

The  purpose  of  this  generic  practice  is  to  define  the  organizatbnal 
expectations  for  the  process  and  make  these  expectations  visible  to  those 
members  ofthe  organization  who  are  affected.  In  general,  senior 
management  is  responsible  for  establishing  and  communicating  guiding 


Not  all  direction  from  senior  management  will  bear  the  label  ‘policy ’The 
existence  of  appropriate  organizational  direction  is  the  expectation  of  this 
generic  practice,  regardless  of  what  it  is  called  or  how  it  is  imparted. 


CAR  Elatxxation 


This  policy  estabfishes  organizational  expectations  for  identifying  and 
systematically  addressing  causal  analysis  of  selected  outcomes. 

CM  Elatxxation 


Generic  Practice 
Elaboration 


This  policy  estabSshes  organizational  expectations  for  establishing  and 
maintaining  baselines,  tracking  and  controlling  changes  to  work  products 
(under  configuration  management),  and  establishing  and  maintaining 
integrity  ofthe  baselines. 


DAR  Elatxjfstion 


This  policy  establishes  organizational  expectations  for  selectively  analyzing 
possible  decisions  using  a  formal  evaluation  process  that  evaluates 
identified  alternatives  against  established  criteria.  The  policy  should  also 
provide  guidance  on  which  decisions  require  a  formal  evaluation  process. 

IPM  Elatxwaton 


This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  the  project's  defined  process  from  project  startup  through  the 
life  ofthe  project  uskig  the  project's  defined  process  in  managing  the 
project,  and  coordinating  and  collaborating  with  relevant  stakeholders. 

MA  Elatxjration 


This  policy  establishes  organizational  expectations  for  for  aligning 
measurement  objectives  and  activities  with  identified  information  needs  and 
project,  organizational,  or  business  objectives  and  for  providing 
measurement  results. 


OPD  Elatxxatlon 


This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  a  set  of  standard  processes  for  use  by  the  organization,  making 
organizational  process  assets  available  across  the  organization,  and 
establishing  mies  and  guidelines  for  teams. 
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3  Tying  It  All  Together 


Now  that  you  have  been  introduced  to  the  components  of  CMMI  models, 
you  need  to  understand  how  they  fit  together  to  meet  your  process 
improvement  needs.  This  chapter  introduces  the  concept  of  levels  and 
shows  how  the  process  areas  are  organized  and  used. 

CMMI-DEV  does  not  specify  that  a  project  or  organization  must  follow  a 
particular  process  flow  or  that  a  certain  number  of  products  be  developed 
per  day  or  specific  performance  targets  be  achieved.  The  model  does 
specify  that  a  project  or  organization  should  have  processes  that  address 
development  related  practices.  To  determine  whether  these  processes  are 
in  place,  a  project  or  organization  maps  its  processes  to  the  process  areas 
in  this  model. 

The  mapping  of  processes  to  process  areas  enables  the  organization  to 
track  its  progress  against  the  CMMI-DEV  model  as  it  updates  or  creates 
processes.  Do  not  expect  that  every  CMMI-DEV  process  area  will  map  one 
to  one  with  your  organization’s  or  project’s  processes. 


Understanding  Levels 


Levels  are  used  in  CMMI-DEV  to  describe  an  evolutionary  path 
recommended  for  an  organization  that  wants  to  improve  the  processes  it 
uses  to  develop  products  or  services.  Levels  can  also  be  the  outcome  of 
the  rating  activity  in  appraisals.^  Appraisals  can  apply  to  entire 
organizations  or  to  smaller  groups  such  as  a  group  of  projects  or  a  division. 

CMMI  supports  two  improvement  paths  using  levels.  One  path  enables 
organizations  to  incrementally  improve  processes  corresponding  to  an 
individual  process  area  (or  group  of  process  areas)  selected  by  the 
organization.  The  other  path  enables  organizations  to  improve  a  set  of 
related  processes  by  incrementally  addressing  successive  sets  of  process 
areas. 

These  two  improvement  paths  are  associated  with  the  two  types  of  levels: 
capability  levels  and  maturity  levels.  These  levels  correspond  to  two 
approaches  to  process  improvement  called  “representations.”  The  two 
representations  are  called  “continuous”  and  “staged.”  Using  the  continuous 
representation  enables  you  to  achieve  “capability  levels.”  Using  the  staged 
representation  enables  you  to  achieve  “maturity  levels.” 


For  more  information  about  appraisais,  refer  to  Appraisai  Requirements  for  CMMi  and  the  Standard  CMMi  Appraisai  Method 
for  Process  improvement  Method  Definition  Document  [SEI  2011a,  SEi  2011b]. 
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To  reach  a  particular  level,  an  organization  must  satisfy  all  of  the  goals  of 
the  process  area  or  set  of  process  areas  that  are  targeted  for  improvement, 
regardless  of  whether  it  is  a  capability  or  a  maturity  level. 

Both  representations  provide  ways  to  improve  your  processes  to  achieve 
business  objectives,  and  both  provide  the  same  essential  content  and  use 
the  same  model  components. 


Structures  of  the  Continuous  and  Staged  Representations 


Figure  3.1  illustrates  the  structures  of  the  continuous  and  staged 
representations.  The  differences  between  the  structures  are  subtle  but 
significant.  The  staged  representation  uses  maturity  levels  to  characterize 
the  overall  state  of  the  organization’s  processes  relative  to  the  model  as  a 
whole,  whereas  the  continuous  representation  uses  capability  levels  to 
characterize  the  state  of  the  organization’s  processes  relative  to  an 
individual  process  area. 

Continuous  Representation 


Process  Areas 


Staged  Representation 


Figure  3.1:  Structure  of  the  Continuous  and  Staged  Representations 
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What  may  strike  you  as  you  compare  these  two  representations  is  their 
similarity.  Both  have  many  of  the  same  components  (e.g.,  process  areas, 
specific  goals,  specific  practices),  and  these  components  have  the  same 
hierarchy  and  configuration. 

What  is  not  readily  apparent  from  the  high-level  view  in  Figure  3.1  is  that 
the  continuous  representation  focuses  on  process  area  capability  as 
measured  by  capability  levels  and  the  staged  representation  focuses  on 
overall  maturity  as  measured  by  maturity  levels.  This  dimension  (the 
capability/maturity  dimension)  of  CMMI  is  used  for  benchmarking  and 
appraisal  activities,  as  well  as  guiding  an  organization’s  improvement 
efforts. 

Capability  levels  apply  to  an  organization’s  process  improvement 
achievement  in  individual  process  areas.  These  levels  are  a  means  for 
incrementally  improving  the  processes  corresponding  to  a  given  process 
area.  The  four  capability  levels  are  numbered  0  through  3. 

Maturity  levels  apply  to  an  organization’s  process  improvement 
achievement  across  multiple  process  areas.  These  levels  are  a  means  of 
improving  the  processes  corresponding  to  a  given  set  of  process  areas  (i.e., 
maturity  level).  The  five  maturity  levels  are  numbered  1  through  5. 

Table  3.1  compares  the  four  capability  levels  to  the  five  maturity  levels. 
Notice  that  the  names  of  two  of  the  levels  are  the  same  in  both 
representations  (i.e..  Managed  and  Defined).  The  differences  are  that  there 
is  no  maturity  level  0;  there  are  no  capability  levels  4  and  5;  and  at  level  1 , 
the  names  used  for  capability  level  1  and  maturity  level  1  are  different. 


Table  3. 1  Comparison  of  Capability  and  Maturity  Levels 


Level 

Continuous  Representation 
Capability  Levels 

Staged  Representation 

Maturity  Levels 

Level  0 

Incomplete 

Level  1 

Performed 

Initial 

Level  2 

Managed 

Managed 

Level  3 

Defined 

Defined 

Level  4 

Quantitatively  Managed 

Level  5 

Optimizing 

The  continuous  representation  is  concerned  with  selecting  both  a  particular 
process  area  to  improve  and  the  desired  capability  level  for  that  process 
area.  In  this  context,  whether  a  process  is  performed  or  incomplete  is 
important.  Therefore,  the  name  “Incomplete”  is  given  to  the  continuous 
representation  starting  point. 
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The  staged  representation  is  concerned  with  selecting  multiple  process 
areas  to  improve  within  a  maturity  level;  whether  individual  processes  are 
performed  or  incomplete  is  not  the  primary  focus.  Therefore,  the  name 
“Initial”  is  given  to  the  staged  representation  starting  point. 

Both  capability  levels  and  maturity  levels  provide  a  way  to  improve  the 
processes  of  an  organization  and  measure  how  well  organizations  can  and 
do  improve  their  processes.  However,  the  associated  approach  to  process 
improvement  is  different. 


Understanding  Capability  Levels 


To  support  those  who  use  the  continuous  representation,  all  CMMI  models 
reflect  capability  levels  in  their  design  and  content. 

The  four  capability  levels,  each  a  layer  in  the  foundation  for  ongoing 
process  improvement,  are  designated  by  the  numbers  0  through  3: 

0.  Incomplete 

1 .  Performed 

2.  Managed 

3.  Defined 

A  capability  level  for  a  process  area  is  achieved  when  all  of  the  generic 
goals  are  satisfied  up  to  that  level.  The  fact  that  capability  levels  2  and  3 
use  the  same  terms  as  generic  goals  2  and  3  is  intentional  because  each  of 
these  generic  goals  and  practices  reflects  the  meaning  of  the  capability 
levels  of  the  goals  and  practices.  (See  the  Generic  Goals  and  Generic 
Practices  section  in  Part  Two  for  more  information  about  generic  goals  and 
practices.)  A  short  description  of  each  capability  level  follows. 

Capability  Level  0:  Incomplete _ 

An  incomplete  process  is  a  process  that  either  is  not  performed  or  is 
partially  performed.  One  or  more  of  the  specific  goals  of  the  process  area 
are  not  satisfied  and  no  generic  goals  exist  for  this  level  since  there  is  no 
reason  to  institutionalize  a  partially  performed  process. 

Capability  Level  1 :  Performed 

A  capability  level  1  process  is  characterized  as  a  performed  process.  A 
performed  process  is  a  process  that  accomplishes  the  needed  work  to 
produce  work  products;  the  specific  goals  of  the  process  area  are  satisfied. 

Although  capability  level  1  results  in  important  improvements,  those 
improvements  can  be  lost  over  time  if  they  are  not  institutionalized.  The 
application  of  institutionalization  (the  CMMI  generic  practices  at  capability 
levels  2  and  3)  helps  to  ensure  that  improvements  are  maintained. 
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Capability  Level  2:  Managed _ 

A  capability  level  2  process  is  characterized  as  a  managed  process.  A 
managed  process  is  a  performed  process  that  is  planned  and  executed  in 
accordance  with  policy;  employs  skilled  people  having  adequate  resources 
to  produce  controlled  outputs;  involves  relevant  stakeholders;  is  monitored, 
controlled,  and  reviewed;  and  is  evaluated  for  adherence  to  its  process 
description. 

The  process  discipline  reflected  by  capability  level  2  helps  to  ensure  that 
existing  practices  are  retained  during  times  of  stress. 

Capability  Level  3:  Defined _ 

A  capability  level  3  process  is  characterized  as  a  defined  process.  A 
defined  process  is  a  managed  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes  according  to  the  organization’s 
tailoring  guidelines;  has  a  maintained  process  description;  and  contributes 
process  related  experiences  to  the  organizational  process  assets. 

A  critical  distinction  between  capability  levels  2  and  3  is  the  scope  of 
standards,  process  descriptions,  and  procedures.  At  capability  level  2,  the 
standards,  process  descriptions,  and  procedures  can  be  quite  different  in 
each  specific  instance  of  the  process  (e.g.,  on  a  particular  project).  At 
capability  level  3,  the  standards,  process  descriptions,  and  procedures  for  a 
project  are  tailored  from  the  organization’s  set  of  standard  processes  to  suit 
a  particular  project  or  organizational  unit  and  therefore  are  more  consistent, 
except  for  the  differences  allowed  by  the  tailoring  guidelines. 

Another  critical  distinction  is  that  at  capability  level  3  processes  are  typically 
described  more  rigorously  than  at  capability  level  2.  A  defined  process 
clearly  states  the  purpose,  inputs,  entry  criteria,  activities,  roles,  measures, 
verification  steps,  outputs,  and  exit  criteria.  At  capability  level  3,  processes 
are  managed  more  proactively  using  an  understanding  of  the 
interrelationships  of  the  process  activities  and  detailed  measures  of  the 
process  and  its  work  products. 

Advancing  Through  Capability  Levels 

The  capability  levels  of  a  process  area  are  achieved  through  the  application 
of  generic  practices  or  suitable  alternatives  to  the  processes  associated 
with  that  process  area. 

Reaching  capability  level  1  for  a  process  area  is  equivalent  to  saying  that 
the  processes  associated  with  that  process  area  are  performed  processes. 

Reaching  capability  level  2  for  a  process  area  is  equivalent  to  saying  that 
there  is  a  policy  that  indicates  you  will  perform  the  process.  There  is  a  plan 
for  performing  it,  resources  are  provided,  responsibilities  are  assigned, 
training  to  perform  it  is  provided,  selected  work  products  related  to 
performing  the  process  are  controlled,  and  so  on.  In  other  words,  a 
capability  level  2  process  can  be  planned  and  monitored  just  like  any 
project  or  support  activity. 
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Reaching  capability  level  3  for  a  process  area  is  equivalent  to  saying  that 
an  organizational  standard  process  exists  associated  with  that  process 
area,  which  can  be  tailored  to  the  needs  of  the  project.  The  processes  in 
the  organization  are  now  more  consistently  defined  and  applied  because 
they  are  based  on  organizational  standard  processes. 

After  an  organization  has  reached  capability  level  3  in  the  process  areas  it 
has  selected  for  improvement,  it  can  continue  its  improvement  journey  by 
addressing  high  maturity  process  areas  (Organizational  Process 
Performance,  Quantitative  Project  Management,  Causal  Analysis  and 
Resolution,  and  Organizational  Performance  Management). 

The  high  maturity  process  areas  focus  on  improving  the  performance  of 
those  processes  already  implemented.  The  high  maturity  process  areas 
describe  the  use  of  statistical  and  other  quantitative  techniques  to  improve 
organizational  and  project  processes  to  better  achieve  business  objectives. 

When  continuing  its  improvement  journey  in  this  way,  an  organization  can 
derive  the  most  benefit  by  first  selecting  the  OPP  and  QPM  process  areas, 
and  bringing  those  process  areas  to  capability  levels  1 , 2,  and  3.  In  doing 
so,  projects  and  organizations  align  the  selection  and  analyses  of 
processes  more  closely  with  their  business  objectives. 

After  the  organization  attains  capability  level  3  in  the  OPP  and  QPM 
process  areas,  the  organization  can  continue  its  improvement  path  by 
selecting  the  CAR  and  0PM  process  areas.  In  doing  so,  the  organization 
analyzes  the  business  performance  using  statistical  and  other  quantitative 
techniques  to  determine  performance  shortfalls,  and  identifies  and  deploys 
process  and  technology  improvements  that  contribute  to  meeting  quality 
and  process  performance  objectives.  Projects  and  the  organization  use 
causal  analysis  to  identify  and  resolve  issues  affecting  performance  and 
promote  the  dissemination  of  best  practices. 


Understanding  Maturity  Leveis 

To  support  those  who  use  the  staged  representation,  all  CMMI  models 
reflect  maturity  levels  in  their  design  and  content.  A  maturity  level  consists 
of  related  specific  and  generic  practices  for  a  predefined  set  of  process 
areas  that  improve  the  organization’s  overall  performance. 

The  maturity  level  of  an  organization  provides  a  way  to  characterize  its 
performance.  Experience  has  shown  that  organizations  do  their  best  when 
they  focus  their  process  improvement  efforts  on  a  manageable  number  of 
process  areas  at  a  time  and  that  those  areas  require  increasing 
sophistication  as  the  organization  improves. 

A  maturity  level  is  a  defined  evolutionary  plateau  for  organizational  process 
improvement.  Each  maturity  level  matures  an  important  subset  of  the 
organization’s  processes,  preparing  it  to  move  to  the  next  maturity  level. 
The  maturity  levels  are  measured  by  the  achievement  of  the  specific  and 
generic  goals  associated  with  each  predefined  set  of  process  areas. 
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The  five  maturity  levels,  each  a  layer  in  the  foundation  for  ongoing  process 
improvement,  are  designated  by  the  numbers  1  through  5: 

1.  Initial 

2.  Managed 

3.  Defined 

4.  Quantitatively  Managed 

5.  Optimizing 

Remember  that  maturity  levels  2  and  3  use  the  same  terms  as  capability 
levels  2  and  3.  This  consistency  of  terminology  was  intentional  because  the 
concepts  of  maturity  levels  and  capability  levels  are  complementary. 

Maturity  levels  are  used  to  characterize  organizational  improvement  relative 
to  a  set  of  process  areas,  and  capability  levels  characterize  organizational 
improvement  relative  to  an  individual  process  area. 

Maturity  Level  1 :  Initial 

At  maturity  level  1 ,  processes  are  usually  ad  hoc  and  chaotic.  The 
organization  usually  does  not  provide  a  stable  environment  to  support 
processes.  Success  in  these  organizations  depends  on  the  competence 
and  heroics  of  the  people  in  the  organization  and  not  on  the  use  of  proven 
processes.  In  spite  of  this  chaos,  maturity  level  1  organizations  often 
produce  products  and  services  that  work,  but  they  frequently  exceed  the 
budget  and  schedule  documented  in  their  plans. 

Maturity  level  1  organizations  are  characterized  by  a  tendency  to 
overcommit,  abandon  their  processes  in  a  time  of  crisis,  and  be  unable  to 
repeat  their  successes. 

Maturity  Level  2:  Managed 

At  maturity  level  2,  the  projects  have  ensured  that  processes  are  planned 
and  executed  in  accordance  with  policy;  the  projects  employ  skilled  people 
who  have  adequate  resources  to  produce  controlled  outputs;  involve 
relevant  stakeholders;  are  monitored,  controlled,  and  reviewed;  and  are 
evaluated  for  adherence  to  their  process  descriptions.  The  process 
discipline  reflected  by  maturity  level  2  helps  to  ensure  that  existing  practices 
are  retained  during  times  of  stress.  When  these  practices  are  in  place, 
projects  are  performed  and  managed  according  to  their  documented  plans. 

Also  at  maturity  level  2,  the  status  of  the  work  products  are  visible  to 
management  at  defined  points  (e.g.,  at  major  milestones,  at  the  completion 
of  major  tasks).  Commitments  are  established  among  relevant  stakeholders 
and  are  revised  as  needed.  Work  products  are  appropriately  controlled.  The 
work  products  and  services  satisfy  their  specified  process  descriptions, 
standards,  and  procedures. 
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Maturity  Level  3:  Defined 

At  maturity  level  3,  processes  are  well  characterized  and  understood,  and 
are  described  in  standards,  procedures,  tools,  and  methods.  The 
organization’s  set  of  standard  processes,  which  is  the  basis  for  maturity 
level  3,  is  established  and  improved  over  time.  These  standard  processes 
are  used  to  establish  consistency  across  the  organization.  Projects 
establish  their  defined  processes  by  tailoring  the  organization’s  set  of 
standard  processes  according  to  tailoring  guidelines.  (See  the  definition  of 
“organization’s  set  of  standard  processes”  in  the  glossary.) 

A  critical  distinction  between  maturity  levels  2  and  3  is  the  scope  of 
standards,  process  descriptions,  and  procedures.  At  maturity  level  2,  the 
standards,  process  descriptions,  and  procedures  can  be  quite  different  in 
each  specific  instance  of  the  process  (e.g.,  on  a  particular  project).  At 
maturity  level  3,  the  standards,  process  descriptions,  and  procedures  for  a 
project  are  tailored  from  the  organization’s  set  of  standard  processes  to  suit 
a  particular  project  or  organizational  unit  and  therefore  are  more  consistent 
except  for  the  differences  allowed  by  the  tailoring  guidelines. 

Another  critical  distinction  is  that  at  maturity  level  3,  processes  are  typically 
described  more  rigorously  than  at  maturity  level  2.  A  defined  process  clearly 
states  the  purpose,  inputs,  entry  criteria,  activities,  roles,  measures, 
verification  steps,  outputs,  and  exit  criteria.  At  maturity  level  3,  processes 
are  managed  more  proactively  using  an  understanding  of  the 
interrelationships  of  process  activities  and  detailed  measures  of  the 
process,  its  work  products,  and  its  services. 

At  maturity  level  3,  the  organization  further  improves  its  processes  that  are 
related  to  the  maturity  level  2  process  areas.  Generic  practices  associated 
with  generic  goal  3  that  were  not  addressed  at  maturity  level  2  are  applied 
to  achieve  maturity  level  3. 

Maturity  Level  4:  Quantitatively  Managed 

At  maturity  level  4,  the  organization  and  projects  establish  quantitative 
objectives  for  quality  and  process  performance  and  use  them  as  criteria  in 
managing  projects.  Quantitative  objectives  are  based  on  the  needs  of  the 
customer,  end  users,  organization,  and  process  implementers.  Quality  and 
process  performance  is  understood  in  statistical  terms  and  is  managed 
throughout  the  life  of  projects. 

For  selected  subprocesses,  specific  measures  of  process  performance  are 
collected  and  statistically  analyzed.  When  selecting  subprocesses  for 
analyses,  it  is  critical  to  understand  the  relationships  between  different 
subprocesses  and  their  impact  on  achieving  the  objectives  for  quality  and 
process  performance.  Such  an  approach  helps  to  ensure  that  subprocess 
monitoring  using  statistical  and  other  quantitative  techniques  is  applied  to 
where  it  has  the  most  overall  value  to  the  business.  Process  performance 
baselines  and  models  can  be  used  to  help  set  quality  and  process 
performance  objectives  that  help  achieve  business  objectives. 
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A  critical  distinction  between  maturity  levels  3  and  4  is  the  predictability  of 
process  performance.  At  maturity  level  4,  the  performance  of  projects  and 
selected  subprocesses  is  controlled  using  statistical  and  other  quantitative 
techniques,  and  predictions  are  based,  in  part,  on  a  statistical  analysis  of 
fine-grained  process  data. 

Maturity  Level  5:  Optimizing 

At  maturity  level  5,  an  organization  continually  improves  its  processes 
based  on  a  quantitative  understanding  of  its  business  objectives  and 
performance  needs.  The  organization  uses  a  quantitative  approach  to 
understand  the  variation  inherent  in  the  process  and  the  causes  of  process 
outcomes. 

Maturity  level  5  focuses  on  continually  improving  process  performance 
through  incremental  and  innovative  process  and  technological 
improvements.  The  organization’s  quality  and  process  performance 
objectives  are  established,  continually  revised  to  reflect  changing  business 
objectives  and  organizational  performance,  and  used  as  criteria  in 
managing  process  improvement.  The  effects  of  deployed  process 
improvements  are  measured  using  statistical  and  other  quantitative 
techniques  and  compared  to  quality  and  process  performance  objectives. 
The  project’s  defined  processes,  the  organization’s  set  of  standard 
processes,  and  supporting  technology  are  targets  of  measurable 
improvement  activities. 

A  critical  distinction  between  maturity  levels  4  and  5  is  the  focus  on 
managing  and  improving  organizational  performance.  At  maturity  level  4, 
the  organization  and  projects  focus  on  understanding  and  controlling 
performance  at  the  subprocess  level  and  using  the  results  to  manage 
projects.  At  maturity  level  5,  the  organization  is  concerned  with  overall 
organizational  performance  using  data  collected  from  multiple  projects. 
Analysis  of  the  data  identifies  shortfalls  or  gaps  in  performance.  These  gaps 
are  used  to  drive  organizational  process  improvement  that  generates 
measureable  improvement  in  performance. 

Advancing  Through  Maturity  Leveis 

Organizations  can  achieve  progressive  improvements  in  their  maturity  by 
achieving  control  first  at  the  project  level  and  continuing  to  the  most 
advanced  level — organization-wide  performance  management  and 
continuous  process  improvement — using  both  qualitative  and  quantitative 
data  to  make  decisions. 

Since  improved  organizational  maturity  is  associated  with  improvement  in 
the  range  of  expected  results  that  can  be  achieved  by  an  organization, 
maturity  is  one  way  of  predicting  general  outcomes  of  the  organization’s 
next  project.  For  instance,  at  maturity  level  2,  the  organization  has  been 
elevated  from  ad  hoc  to  disciplined  by  establishing  sound  project 
management.  As  the  organization  achieves  generic  and  specific  goals  for 
the  set  of  process  areas  in  a  maturity  level,  it  increases  its  organizational 
maturity  and  reaps  the  benefits  of  process  improvement.  Because  each 
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maturity  level  forms  a  necessary  foundation  for  the  next  level,  trying  to  skip 
maturity  levels  is  usually  counterproductive. 

At  the  same  time,  recognize  that  process  improvement  efforts  should  focus 
on  the  needs  of  the  organization  in  the  context  of  its  business  environment 
and  that  process  areas  at  higher  maturity  levels  can  address  the  current 
and  future  needs  of  an  organization  or  project. 

For  example,  organizations  seeking  to  move  from  maturity  level  1  to 
maturity  level  2  are  frequently  encouraged  to  establish  a  process  group, 
which  is  addressed  by  the  Organizational  Process  Focus  process  area  at 
maturity  level  3.  Although  a  process  group  is  not  a  necessary  characteristic 
of  a  maturity  level  2  organization,  it  can  be  a  useful  part  of  the 
organization’s  approach  to  achieving  maturity  level  2. 

This  situation  is  sometimes  characterized  as  establishing  a  maturity  level  1 
process  group  to  bootstrap  the  maturity  level  1  organization  to  maturity  level 
2.  Maturity  level  1  process  improvement  activities  may  depend  primarily  on 
the  insight  and  competence  of  the  process  group  until  an  infrastructure  to 
support  more  disciplined  and  widespread  improvement  is  in  place. 

Organizations  can  institute  process  improvements  anytime  they  choose, 
even  before  they  are  prepared  to  advance  to  the  maturity  level  at  which  the 
specific  practice  is  recommended.  In  such  situations,  however, 
organizations  should  understand  that  the  success  of  these  improvements  is 
at  risk  because  the  foundation  for  their  successful  institutionalization  has 
not  been  completed.  Processes  without  the  proper  foundation  can  fail  at  the 
point  they  are  needed  most — under  stress. 

A  defined  process  that  is  characteristic  of  a  maturity  level  3  organization 
can  be  placed  at  great  risk  if  maturity  level  2  management  practices  are 
deficient.  For  example,  management  may  commit  to  a  poorly  planned 
schedule  or  fail  to  control  changes  to  baselined  requirements.  Similarly, 
many  organizations  prematurely  collect  the  detailed  data  characteristic  of 
maturity  level  4  only  to  find  the  data  uninterpretable  because  of 
inconsistencies  in  processes  and  measurement  definitions. 

Another  example  of  using  processes  associated  with  higher  maturity  level 
process  areas  is  in  the  building  of  products.  Certainly,  we  would  expect 
maturity  level  1  organizations  to  perform  requirements  analysis,  design, 
product  integration,  and  verification.  However,  these  activities  are  not 
described  until  maturity  level  3,  where  they  are  defined  as  coherent,  well- 
integrated  engineering  processes.  The  maturity  level  3  engineering  process 
complements  a  maturing  project  management  capability  put  in  place  so  that 
the  engineering  improvements  are  not  lost  by  an  ad  hoc  management 
process. 


Process  Areas 


Process  areas  are  viewed  differently  in  the  two  representations.  Figure  3.2 
compares  views  of  how  process  areas  are  used  in  the  continuous 
representation  and  the  staged  representation. 
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Figure  3.2:  Process  Areas  in  the  Continuous  and  Staged  Representations 

The  continuous  representation  enables  the  organization  to  choose  the 
focus  of  its  process  improvement  efforts  by  choosing  those  process  areas, 
or  sets  of  interrelated  process  areas,  that  best  benefit  the  organization  and 
its  business  objectives.  Although  there  are  some  limits  on  what  an 
organization  can  choose  because  of  the  dependencies  among  process 
areas,  the  organization  has  considerable  freedom  in  its  selection. 
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To  support  those  who  use  the  continuous  representation,  process  areas  are 
organized  into  four  categories:  Process  Management,  Project  Management, 
Engineering,  and  Support.  These  categories  emphasize  some  of  the  key 
relationships  that  exist  among  the  process  areas. 

Sometimes  an  informal  grouping  of  process  areas  is  mentioned:  high 
maturity  process  areas.  The  four  high  maturity  process  areas  are: 
Organizational  Process  Performance,  Quantitative  Project  Management, 
Organizational  Performance  Management,  and  Causal  Analysis  and 
Resolution.  These  process  areas  focus  on  improving  the  performance  of 
implemented  processes  that  most  closely  relate  to  the  organization’s 
business  objectives. 

Once  you  select  process  areas,  you  must  also  select  how  much  you  would 
like  to  mature  processes  associated  with  those  process  areas  (i.e.,  select 
the  appropriate  capability  level).  Capability  levels  and  generic  goals  and 
practices  support  the  improvement  of  processes  associated  with  individual 
process  areas.  For  example,  an  organization  may  wish  to  reach  capability 
level  2  in  one  process  area  and  capability  level  3  in  another.  As  the 
organization  reaches  a  capability  level,  it  sets  its  sights  on  the  next 
capability  level  for  one  of  these  same  process  areas  or  decides  to  widen  its 
view  and  address  a  larger  number  of  process  areas.  Once  it  reaches 
capability  level  3  in  most  of  the  process  areas,  the  organization  can  shift  its 
attention  to  the  high  maturity  process  areas  and  can  track  the  capability  of 
each  through  capability  level  3. 

The  selection  of  a  combination  of  process  areas  and  capability  levels  is 
typically  described  in  a  “target  profile.”  A  target  profile  defines  all  of  the 
process  areas  to  be  addressed  and  the  targeted  capability  level  for  each. 
This  profile  governs  which  goals  and  practices  the  organization  will  address 
in  its  process  improvement  efforts. 

Most  organizations,  at  minimum,  target  capability  level  1  for  the  process 
areas  they  select,  which  requires  that  all  of  these  process  areas’  specific 
goals  be  achieved.  However,  organizations  that  target  capability  levels 
higher  than  1  concentrate  on  the  institutionalization  of  selected  processes  in 
the  organization  by  implementing  generic  goals  and  practices. 

The  staged  representation  provides  a  path  of  improvement  from  maturity 
level  1  to  maturity  level  5  that  involves  achieving  the  goals  of  the  process 
areas  at  each  maturity  level.  To  support  those  who  use  the  staged 
representation,  process  areas  are  grouped  by  maturity  level,  indicating 
which  process  areas  to  implement  to  achieve  each  maturity  level. 

For  example,  at  maturity  level  2,  there  is  a  set  of  process  areas  that  an 
organization  would  use  to  guide  its  process  improvement  until  it  could 
achieve  all  the  goals  of  all  these  process  areas.  Once  maturity  level  2  is 
achieved,  the  organization  focuses  its  efforts  on  maturity  level  3  process 
areas,  and  so  on.  The  generic  goals  that  apply  to  each  process  area  are 
also  predetermined.  Generic  goal  2  applies  to  maturity  level  2  and  generic 
goal  3  applies  to  maturity  levels  3  through  5. 
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Table  3.2  provides  a  list  of  CMMI-DEV  process  areas  and  their  associated 
categories  and  maturity  levels. 


Table  3.2  Process  Areas,  Categories,  and  Maturity  Levels 


Process  Area 

Category 

Maturity  Level 

Causal  Analysis  and  Resolution  (CAR) 

Support 

5 

Configuration  Management  (CM) 

Support 

2 

Decision  Analysis  and  Resolution 
(DAR) 

Support 

3 

Integrated  Project  Management  (IPM) 

Project 

Management 

3 

Measurement  and  Analysis  (MA) 

Support 

2 

Organizational  Process  Definition 
(OPD) 

Process 

Management 

3 

Organizational  Process  Focus  (OPF) 

Process 

Management 

3 

Organizational  Performance 

Management  (0PM) 

Process 

Management 

5 

Organizational  Process  Performance 
(OPP) 

Process 

Management 

4 

Organizational  Training  (OT) 

Process 

Management 

3 

Product  Integration  (PI) 

Engineering 

3 

Project  Monitoring  and  Control  (PMC) 

Project 

Management 

2 

Project  Planning  (PP) 

Project 

Management 

2 

Process  and  Product  Ouality  Assurance 
(PPOA) 

Support 

2 

Ouantitative  Project  Management 
(0PM) 

Project 

Management 

4 

Requirements  Development  (RD) 

Engineering 

3 

Requirements  Management  (REOM) 

Project 

Management 

2 

Risk  Management  (RSKM) 

Project 

Management 

3 

Supplier  Agreement  Management 
(SAM) 

Project 

Management 

2 

Technical  Solution  (TS) 

Engineering 

3 
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Validation  (VAL) 

Engineering 

3 

Verification  (VER) 

Engineering 

3 

Equivalent  Staging 


Equivalent  staging  is  a  way  to  compare  results  from  using  the  continuous 
representation  to  results  from  using  the  staged  representation.  In  essence, 
if  you  measure  improvement  relative  to  selected  process  areas  using 
capability  levels  in  the  continuous  representation,  how  do  you  translate  that 
work  into  maturity  levels?  Is  this  translation  possible? 

Up  to  this  point,  we  have  not  discussed  process  appraisals  in  much  detail. 
The  SCAMPI®^  method®  is  used  to  appraise  organizations  using  CMMI,  and 
one  result  of  an  appraisal  is  a  rating  [SEI  201 1  a,  Ahern  2005].  If  the 
continuous  representation  is  used  for  an  appraisal,  the  rating  is  a  “capability 
level  profile.”  If  the  staged  representation  is  used  for  an  appraisal,  the  rating 
is  a  “maturity  level  rating”  (e.g.,  maturity  level  3). 

A  capability  level  profile  is  a  list  of  process  areas  and  the  corresponding 
capability  level  achieved  for  each.  This  profile  enables  an  organization  to 
track  its  capability  level  by  process  area.  The  profile  is  called  an 
“achievement  profile”  when  it  represents  the  organization’s  actual  progress 
for  each  process  area.  Alternatively,  the  profile  is  called  a  “target  profile” 
when  it  represents  the  organization’s  planned  process  improvement 
objectives. 

Figure  3.3  illustrates  a  combined  target  and  achievement  profile.  The  gray 
portion  of  each  bar  represents  what  has  been  achieved.  The  unshaded 
portion  represents  what  remains  to  be  accomplished  to  meet  the  target 
profile. 


®  The  Standard  CMMI  Appraisal  Method  for  Process  Improvement  (SCAMPI)  method  is  described  in  Chapter  5. 
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Figure  3.3:  Example  Combined  Target  and  Achievement  Profile 

An  achievement  profile,  when  compared  with  a  target  profile,  enables  an 
organization  to  plan  and  track  its  progress  for  each  selected  process  area. 
Maintaining  capability  level  profiles  is  advisable  when  using  the  continuous 
representation. 

Target  staging  is  a  sequence  of  target  profiles  that  describes  the  path  of 
process  improvement  to  be  followed  by  the  organization.  When  building 
target  profiles,  the  organization  should  pay  attention  to  the  dependencies 
between  generic  practices  and  process  areas.  If  a  generic  practice  depends 
on  a  process  area,  either  to  carry  out  the  generic  practice  or  to  provide  a 
prerequisite  work  product,  the  generic  practice  can  be  much  less  effective 
when  the  process  area  is  not  implemented.® 

Although  the  reasons  to  use  the  continuous  representation  are  many, 
ratings  consisting  of  capability  level  profiles  are  limited  in  their  ability  to 
provide  organizations  with  a  way  to  generally  compare  themselves  with 
other  organizations.  Capability  level  profiles  can  be  used  if  each 
organization  selects  the  same  process  areas;  however,  maturity  levels  have 
been  used  to  compare  organizations  for  years  and  already  provide 
predefined  sets  of  process  areas. 

Because  of  this  situation,  equivalent  staging  was  created.  Equivalent 
staging  enables  an  organization  using  the  continuous  representation  to 
convert  a  capability  level  profile  to  the  associated  maturity  level  rating. 


See  Table  6.2  in  the  Generic  Goals  and  Generic  Practices  section  of  Part  Two  for  more  information  about  the  dependencies 
between  generic  practices  and  process  areas. 
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The  most  effective  way  to  depict  equivalent  staging  is  to  provide  a 
sequence  of  target  profiles,  each  of  which  is  equivalent  to  a  maturity  level 
rating  of  the  staged  representation  reflected  in  the  process  areas  listed  in 
the  target  profile.  The  result  is  a  target  staging  that  is  equivalent  to  the 
maturity  levels  of  the  staged  representation. 

Figure  3.4  shows  a  summary  of  the  target  profiles  that  must  be  achieved 
when  using  the  continuous  representation  to  be  equivalent  to  maturity 
levels  2  through  5.  Each  shaded  area  in  the  capability  level  columns 
represents  a  target  profile  that  is  equivalent  to  a  maturity  level. 


Figure  3.4:  Target  Profiles  and  Equivalent  Staging 

The  following  rules  summarize  equivalent  staging: 

•  To  achieve  maturity  level  2,  all  process  areas  assigned  to  maturity  level 
2  must  achieve  capability  level  2  or  3. 

•  To  achieve  maturity  level  3,  all  process  areas  assigned  to  maturity 
levels  2  and  3  must  achieve  capability  level  3. 
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•  To  achieve  maturity  level  4,  all  process  areas  assigned  to  maturity 
levels  2,  3,  and  4  must  achieve  capability  level  3. 

•  To  achieve  maturity  level  5,  all  process  areas  must  achieve  capability 
level  3. 


Achieving  High  Maturity 


When  using  the  staged  representation,  you  attain  high  maturity  when  you 
achieve  maturity  level  4  or  5.  Achieving  maturity  level  4  involves 
implementing  all  process  areas  for  maturity  levels  2,  3,  and  4.  Likewise, 
achieving  maturity  level  5  involves  implementing  all  process  areas  for 
maturity  levels  2,  3,  4,  and  5. 

When  using  the  continuous  representation,  you  attain  high  maturity  using 
the  equivalent  staging  concept.  High  maturity  that  is  equivalent  to  staged 
maturity  level  4  using  equivalent  staging  is  attained  when  you  achieve 
capability  level  3  for  all  process  areas  except  for  Organizational 
Performance  Management  (0PM)  and  Causal  Analysis  and  Resolution 
(CAR).  High  maturity  that  is  equivalent  to  staged  maturity  level  5  using 
equivalent  staging  is  attained  when  you  achieve  capability  level  3  for  all 
process  areas. 
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4  Relationships  Among  Process  Areas 


In  this  chapter  we  describe  the  key  relationships  among  process  areas  to 
help  you  see  the  organization’s  view  of  process  improvement  and  how 
process  areas  depend  on  the  implementation  of  other  process  areas. 

The  relationships  among  multiple  process  areas,  including  the  information 
and  artifacts  that  flow  from  one  process  area  to  another — illustrated  by  the 
figures  and  descriptions  in  this  chapter — help  you  to  see  a  larger  view  of 
process  implementation  and  improvement. 

Successful  process  improvement  initiatives  must  be  driven  by  the  business 
objectives  of  the  organization.  For  example,  a  common  business  objective 
is  to  reduce  the  time  it  takes  to  get  a  product  to  market.  The  process 
improvement  objective  derived  from  that  might  be  to  improve  the  project 
management  processes  to  ensure  on-time  delivery;  those  improvements 
rely  on  best  practices  in  the  Project  Planning  and  Project  Monitoring  and 
Control  process  areas. 

Although  we  group  process  areas  in  this  chapter  to  simplify  the  discussion 
of  their  relationships,  process  areas  often  interact  and  have  an  effect  on 
one  another  regardless  of  their  group,  category,  or  level.  For  example,  the 
Decision  Analysis  and  Resolution  process  area  (a  Support  process  area  at 
maturity  level  3)  contains  specific  practices  that  address  the  formal 
evaluation  process  used  in  the  Technical  Solution  process  area  for 
selecting  a  technical  solution  from  alternative  solutions. 

Being  aware  of  the  key  relationships  that  exist  among  CMMI  process  areas 
will  help  you  apply  CMMI  in  a  useful  and  productive  way.  Relationships 
among  process  areas  are  described  in  more  detail  in  the  references  of  each 
process  area  and  specifically  in  the  Related  Process  Areas  section  of  each 
process  area  in  Part  Two.  Refer  to  Chapter  2  for  more  information  about 
references. 


Process  Management 


Process  Management  process  areas  contain  the  cross-project  activities 
related  to  defining,  planning,  deploying,  implementing,  monitoring, 
controlling,  appraising,  measuring,  and  improving  processes. 

The  five  Process  Management  process  areas  in  CMMI-DEV  are  as  follows: 

•  Organizational  Process  Definition  (OPD) 

•  Organizational  Process  Focus  (OPF) 

•  Organizational  Performance  Management  (0PM) 
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•  Organizational  Process  Performance  (OPP) 

•  Organizational  Training  (OT) 

Basic  Process  Management  Process  Areas 

The  Basic  Process  Management  process  areas  provide  the  organization 
with  a  capability  to  document  and  share  best  practices,  organizational 
process  assets,  and  learning  across  the  organization. 

Figure  4.1  provides  a  bird’s-eye  view  of  the  interactions  among  the  Basic 
Process  Management  process  areas  and  with  other  process  area 
categories.  As  illustrated  in  Figure  4.1,  the  Organizational  Process  Focus 
process  area  helps  the  organization  to  plan,  implement,  and  deploy 
organizational  process  improvements  based  on  an  understanding  of  the 
current  strengths  and  weaknesses  of  the  organization’s  processes  and 
process  assets. 


Process  improvement  proposals;  participation  in 
defining,  assessing,  and  deploying  processes 


OPD  =  Organizational  Process  Definition 
OPF  =  Organizational  Process  Focus 
OT  =  Organizational  Training 


Figure  4.1:  Basic  Process  Management  Process  Areas 

Candidate  improvements  to  the  organization’s  processes  are  obtained 
through  various  sources.  These  activities  include  process  improvement 
proposals,  measurement  of  the  processes,  lessons  learned  in  implementing 
the  processes,  and  results  of  process  appraisal  and  product  evaluation 
activities. 
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The  Organizational  Process  Definition  process  area  establishes  and 
maintains  the  organization’s  set  of  standard  processes,  work  environment 
standards,  and  other  assets  based  on  the  process  needs  and  objectives  of 
the  organization.  These  other  assets  include  descriptions  of  lifecycle 
models,  process  tailoring  guidelines,  and  process  related  documentation 
and  data. 

Projects  tailor  the  organization’s  set  of  standard  processes  to  create  their 
defined  processes.  The  other  assets  support  tailoring  as  well  as 
implementation  of  the  defined  processes. 

Experiences  and  work  products  from  performing  these  defined  processes, 
including  measurement  data,  process  descriptions,  process  artifacts,  and 
lessons  learned,  are  incorporated  as  appropriate  into  the  organization’s  set 
of  standard  processes  and  other  assets. 

The  Organizational  Training  process  area  identifies  the  strategic  training 
needs  of  the  organization  as  well  as  the  tactical  training  needs  that  are 
common  across  projects  and  support  groups.  In  particular,  training  is 
developed  or  obtained  to  develop  the  skills  required  to  perform  the 
organization’s  set  of  standard  processes.  The  main  components  of  training 
include  a  managed  training  development  program,  documented  plans,  staff 
with  appropriate  knowledge,  and  mechanisms  for  measuring  the 
effectiveness  of  the  training  program. 

Advanced  Process  Management  Process  Areas 

The  Advanced  Process  Management  process  areas  provide  the 
organization  with  an  improved  capability  to  achieve  its  quantitative 
objectives  for  quality  and  process  performance. 

Figure  4.2  provides  a  bird’s-eye  view  of  the  interactions  among  the 
Advanced  Process  Management  process  areas  and  with  other  process 
area  categories.  Each  of  the  Advanced  Process  Management  process 
areas  depends  on  the  ability  to  develop  and  deploy  processes  and 
supporting  assets.  The  Basic  Process  Management  process  areas  provide 
this  ability. 
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0PM  =  Organizational  Performance  Management 
OPP  =  Organizational  Process  Performance 

Figure  4.2:  Advanced  Process  Management  Process  Areas 

As  illustrated  in  Figure  4.2,  the  Organizational  Process  Performance 
process  area  derives  quantitative  objectives  for  quality  and  process 
performance  from  the  organization’s  business  objectives.  The  organization 
provides  projects  and  support  groups  with  common  measures,  process 
performance  baselines,  and  process  performance  models. 

These  additional  organizational  assets  support  composing  a  defined 
process  that  can  achieve  the  project’s  quality  and  process  performance 
objectives  and  support  quantitative  management.  The  organization 
analyzes  the  process  performance  data  collected  from  these  defined 
processes  to  develop  a  quantitative  understanding  of  product  quality, 
service  quality,  and  process  performance  of  the  organization’s  set  of 
standard  processes. 

In  Organizational  Performance  Management,  process  performance 
baselines  and  models  are  analyzed  to  understand  the  organization’s  ability 
to  meet  its  business  objectives  and  to  derive  quality  and  process 
performance  objectives.  Based  on  this  understanding,  the  organization 
proactively  selects  and  deploys  incremental  and  innovative  improvements 
that  measurably  improve  the  organization’s  performance. 

The  selection  of  improvements  to  deploy  is  based  on  a  quantitative 
understanding  of  the  likely  benefits  and  predicted  costs  of  deploying 
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candidate  improvements.  The  organization  can  also  adjust  business 
objectives  and  quality  and  process  performance  objectives  as  appropriate. 


Project  Management 


Project  Management  process  areas  cover  the  project  management 
activities  related  to  planning,  monitoring,  and  controlling  the  project. 

The  seven  Project  Management  process  areas  in  CMMI-DEV  are  as 
follows: 

•  Integrated  Project  Management  (IPM) 

•  Project  Monitoring  and  Control  (PMC) 

•  Project  Planning  (PP) 

•  Quantitative  Project  Management  (QPM) 

•  Requirements  Management  (REQM) 

•  Risk  Management  (RSKM) 

•  Supplier  Agreement  Management  (SAM) 

Basic  Project  Management  Process  Areas 

The  Basic  Project  Management  process  areas  address  the  activities  related 
to  establishing  and  maintaining  the  project  plan,  establishing  and 
maintaining  commitments,  monitoring  progress  against  the  plan,  taking 
corrective  action,  and  managing  supplier  agreements. 

Figure  4.3  provides  a  bird’s-eye  view  of  the  interactions  among  the  Basic 
Project  Management  process  areas  and  with  other  process  area  categories. 
As  illustrated  in  Figure  4.3,  the  Project  Planning  process  area  includes 
developing  the  project  plan,  involving  relevant  stakeholders,  obtaining 
commitment  to  the  plan,  and  maintaining  the  plan. 
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PMC  =  Project  Monitoring  and  Control 
PP  =  Project  Pianning 
REQM  =  Requirements  Management 
SAM  =  Suppiier  Agreement  Management 

Figure  4.3:  Basic  Project  Management  Process  Areas 

Planning  begins  with  requirements  that  define  the  product  and  project 
(“What  to  Build”  in  Figure  4.3).  The  project  plan  covers  the  various  project 
management  and  development  activities  performed  by  the  project.  The 
project  reviews  other  plans  that  affect  the  project  from  various  relevant 
stakeholders  and  establishes  commitments  with  those  stakeholders  for  their 
contributions  to  the  project.  For  example,  these  plans  cover  configuration 
management,  verification,  and  measurement  and  analysis. 

The  Project  Monitoring  and  Control  process  area  contains  practices  for 
monitoring  and  controlling  activities  and  taking  corrective  action.  The  project 
plan  specifies  the  frequency  of  progress  reviews  and  the  measures  used  to 
monitor  progress.  Progress  is  determined  primarily  by  comparing  project 
status  to  the  plan.  When  the  actual  status  deviates  significantly  from  the 
expected  values,  corrective  actions  are  taken  as  appropriate.  These  actions 
can  include  replanning,  which  requires  using  Project  Planning  practices. 

The  Requirements  Management  process  area  maintains  the  requirements. 

It  describes  activities  for  obtaining  and  controlling  requirement  changes  and 
ensuring  that  other  relevant  plans  and  data  are  kept  current.  It  provides 
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traceability  of  requirements  from  customer  requirements  to  product 
requirements  to  product  component  requirements. 

Requirements  Management  ensures  that  changes  to  requirements  are 
reflected  in  project  plans,  activities,  and  work  products.  This  cycle  of 
changes  can  affect  the  Engineering  process  areas;  thus,  requirements 
management  is  a  dynamic  and  often  recursive  sequence  of  events.  The 
Requirements  Management  process  area  is  fundamental  to  a  controlled 
and  disciplined  engineering  process. 

The  Supplier  Agreement  Management  process  area  addresses  the  need  of 
the  project  to  acquire  those  portions  of  work  that  are  produced  by  suppliers. 
Sources  of  products  that  can  be  used  to  satisfy  project  requirements  are 
proactively  identified.  The  supplier  is  selected,  and  a  supplier  agreement  is 
established  to  manage  the  supplier. 

The  supplier’s  progress  and  performance  are  tracked  as  specified  in  the 
supplier  agreement,  and  the  supplier  agreement  is  revised  as  appropriate. 
Acceptance  reviews  and  tests  are  conducted  on  the  supplier-produced 
product  component. 

Advanced  Project  Management  Process  Areas 

The  Advanced  Project  Management  process  areas  address  activities  such 
as  establishing  a  defined  process  that  is  tailored  from  the  organization’s  set 
of  standard  processes,  establishing  the  project  work  environment  from  the 
organization’s  work  environment  standards,  coordinating  and  collaborating 
with  relevant  stakeholders,  forming  and  sustaining  teams  for  the  conduct  of 
projects,  quantitatively  managing  the  project,  and  managing  risk. 

Figure  4.4  provides  a  bird’s-eye  view  of  the  interactions  among  the 
Advanced  Project  Management  process  areas  and  with  other  process  area 
categories.  Each  Advanced  Project  Management  process  area  depends  on 
the  ability  to  plan,  monitor,  and  control  the  project.  The  Basic  Project 
Management  process  areas  provide  this  ability. 
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Figure  4.4:  Advanced  Project  Management  Process  Areas 

The  Integrated  Project  Management  process  area  establishes  and 
maintains  the  project’s  defined  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes  (Organizational  Process 
Definition).  The  project  is  managed  using  the  project’s  defined  process. 

The  project  uses  and  contributes  to  the  organizational  process  assets,  the 
project’s  work  environment  is  established  and  maintained  from  the 
organization’s  work  environment  standards,  and  teams  are  established 
using  the  organization’s  rules  and  guidelines.  The  project’s  relevant 
stakeholders  coordinate  their  efforts  in  a  timely  manner  through  the 
identification,  negotiation,  and  tracking  of  critical  dependencies  and  the 
resolution  of  coordination  issues. 

Although  risk  identification  and  monitoring  are  covered  in  the  Project 
Planning  and  Project  Monitoring  and  Control  process  areas,  the  Risk 
Management  process  area  takes  a  continuing,  forward-looking  approach  to 
managing  risks  with  activities  that  include  identification  of  risk  parameters, 
risk  assessments,  and  risk  mitigation. 
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The  Quantitative  Project  Management  process  area  establishes  objectives 
for  quality  and  process  performance,  composes  a  defined  process  that  can 
help  achieve  those  objectives,  and  quantitatively  manages  the  project.  The 
project’s  quality  and  process  performance  objectives  are  based  on  the 
objectives  established  by  the  organization  and  the  customer. 

The  project’s  defined  process  is  composed  using  statistical  and  other 
quantitative  techniques.  Such  an  analysis  enables  the  project  to  predict 
whether  it  will  achieve  its  quality  and  process  performance  objectives. 

Based  on  the  prediction,  the  project  can  adjust  the  defined  process  or  can 
negotiate  changes  to  quality  and  process  performance  objectives.  As  the 
project  progresses,  the  performance  of  selected  subprocesses  is  carefully 
monitored  to  help  evaluate  whether  the  project  is  on  track  to  achieving  its 
objectives. 


Engineering 


Engineering  process  areas  cover  the  development  and  maintenance 
activities  that  are  shared  across  engineering  disciplines.  The  Engineering 
process  areas  were  written  using  general  engineering  terminology  so  that 
any  technical  discipline  involved  in  the  product  development  process  (e.g., 
software  engineering,  mechanical  engineering)  can  use  them  for  process 
improvement. 

The  Engineering  process  areas  also  integrate  the  processes  associated 
with  different  engineering  disciplines  into  a  single  product  development 
process,  supporting  a  product  oriented  process  improvement  strategy.  Such 
a  strategy  targets  essential  business  objectives  rather  than  specific 
technical  disciplines.  This  approach  to  processes  effectively  avoids  the 
tendency  toward  an  organizational  “stovepipe”  mentality. 

The  Engineering  process  areas  apply  to  the  development  of  any  product  or 
service  in  the  development  domain  (e.g.,  software  products,  hardware 
products,  services,  processes). 

The  five  Engineering  process  areas  in  CMMI-DEV  are  as  follows: 

•  Product  Integration  (PI) 

•  Requirements  Development  (RD) 

•  Technical  Solution  (TS) 

•  Validation  (VAL) 

•  Verification  (VER) 

Figure  4.5  provides  a  bird’s-eye  view  of  the  interactions  among  the  six 
Engineering  process  areas. 
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Figure  4.5:  Engineering  Process  Areas 

The  Requirements  Development  process  area  identifies  customer  needs 
and  translates  these  needs  into  product  requirements.  The  set  of  product 
requirements  is  analyzed  to  produce  a  high-level  conceptual  solution.  This 
set  of  requirements  is  then  allocated  to  establish  an  initial  set  of  product 
component  requirements. 

Other  requirements  that  help  define  the  product  are  derived  and  allocated 
to  product  components.  This  set  of  product  and  product  component 
requirements  clearly  describes  the  product’s  performance,  quality  attributes, 
design  features,  verification  requirements,  etc.,  in  terms  the  developer 
understands  and  uses. 

The  Requirements  Development  process  area  supplies  requirements  to  the 
Technical  Solution  process  area,  where  the  requirements  are  converted  into 
the  product  architecture,  product  component  designs,  and  product 
components  (e.g.,  by  coding,  fabrication).  Requirements  are  also  supplied 
to  the  Product  Integration  process  area,  where  product  components  are 
combined  and  interfaces  are  verified  to  ensure  that  they  meet  the  interface 
requirements  supplied  by  Requirements  Development. 
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The  Technical  Solution  process  area  develops  technical  data  packages  for 
product  components  to  be  used  by  the  Product  Integration  or  Supplier 
Agreement  Management  process  area.  Alternative  solutions  are  examined 
to  select  the  optimum  design  based  on  established  criteria.  These  criteria 
can  be  significantly  different  across  products,  depending  on  product  type, 
operational  environment,  performance  requirements,  support  requirements, 
and  cost  or  delivery  schedules.  The  task  of  selecting  the  final  solution 
makes  use  of  the  specific  practices  in  the  Decision  Analysis  and  Resolution 
process  area. 

The  Technical  Solution  process  area  relies  on  the  specific  practices  in  the 
Verification  process  area  to  perform  design  verification  and  peer  reviews 
during  design  and  prior  to  final  build. 

The  Verification  process  area  ensures  that  selected  work  products  meet  the 
specified  requirements.  The  Verification  process  area  selects  work  products 
and  verification  methods  that  will  be  used  to  verify  work  products  against 
specified  requirements.  Verification  is  generally  an  incremental  process, 
starting  with  product  component  verification  and  usually  concluding  with 
verification  of  fully  assembled  products. 

Verification  also  addresses  peer  reviews.  Peer  reviews  are  a  proven 
method  for  removing  defects  early  and  provide  valuable  insight  into  the 
work  products  and  product  components  being  developed  and  maintained. 

The  Validation  process  area  incrementally  validates  products  against  the 
customer’s  needs.  Validation  can  be  performed  in  the  operational 
environment  or  in  a  simulated  operational  environment.  Coordination  with 
the  customer  on  validation  requirements  is  an  important  element  of  this 
process  area. 

The  scope  of  the  Validation  process  area  includes  validation  of  products, 
product  components,  selected  intermediate  work  products,  and  processes. 
These  validated  elements  can  often  require  reverification  and  revalidation. 
Issues  discovered  during  validation  are  usually  resolved  in  the 
Requirements  Development  or  Technical  Solution  process  area. 

The  Product  Integration  process  area  contains  the  specific  practices 
associated  with  generating  an  integration  strategy,  integrating  product 
components,  and  delivering  the  product  to  the  customer. 

Product  Integration  uses  the  specific  practices  of  both  Verification  and 
Validation  in  implementing  the  product  integration  process.  Verification 
practices  verify  the  interfaces  and  interface  requirements  of  product 
components  prior  to  product  integration.  Interface  verification  is  an  essential 
event  in  the  integration  process.  During  product  integration  in  the 
operational  environment,  the  specific  practices  of  the  Validation  process 
area  are  used. 
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Recursion  and  Iteration  of  Engineering  Processes 

Most  process  standards  agree  that  there  are  two  ways  that  processes  can 
be  applied.  These  two  ways  are  called  recursion  and  iteration. 

Recursion  occurs  when  a  process  is  applied  to  successive  levels  of  system 
elements  within  a  system  structure.  The  outcomes  of  one  application  are 
used  as  inputs  to  the  next  level  in  the  system  structure.  For  example,  the 
verification  process  is  designed  to  apply  to  the  entire  assembled  product, 
the  major  product  components,  and  even  components  of  components.  How 
far  into  the  product  you  apply  the  verification  process  depends  entirely  on 
the  size  and  complexity  of  the  end  product. 

Iteration  occurs  when  processes  are  repeated  at  the  same  system  level. 
New  information  is  created  by  the  implementation  of  one  process  that  feeds 
that  information  back  into  a  related  process.  This  new  information  typically 
raises  questions  that  must  be  resolved  before  completing  the  processes. 

For  example,  iteration  will  most  likely  occur  between  requirements 
development  and  technical  solution.  Reapplication  of  the  processes  can 
resolve  the  questions  that  are  raised.  Iteration  can  ensure  quality  prior  to 
applying  the  next  process. 

Engineering  processes  (e.g.,  requirements  development,  verification)  are 
implemented  repeatedly  on  a  product  to  ensure  that  these  engineering 
processes  have  been  adequately  addressed  before  delivery  to  the 
customer.  Further,  engineering  processes  are  applied  to  components  of  the 
product. 

For  example,  some  questions  that  are  raised  by  processes  associated  with 
the  Verification  and  Validation  process  areas  can  be  resolved  by  processes 
associated  with  the  Requirements  Development  or  Product  Integration 
process  area.  Recursion  and  iteration  of  these  processes  enable  the  project 
to  ensure  quality  in  all  components  of  the  product  before  it  is  delivered  to 
the  customer. 

The  project  management  process  areas  can  likewise  be  recursive  because 
sometimes  projects  are  nested  within  projects. 


Support 


Support  process  areas  cover  the  activities  that  support  product 
development  and  maintenance.  The  Support  process  areas  address 
processes  that  are  used  in  the  context  of  performing  other  processes.  In 
general,  the  Support  process  areas  address  processes  that  are  targeted 
toward  the  project  and  can  address  processes  that  apply  more  generally  to 
the  organization. 

For  example.  Process  and  Product  Quality  Assurance  can  be  used  with  all 
the  process  areas  to  provide  an  objective  evaluation  of  the  processes  and 
work  products  described  in  all  the  process  areas. 

The  five  Support  process  areas  in  CMMI-DEV  are  as  follows: 
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•  Causal  Analysis  and  Resolution  (CAR) 

•  Configuration  Management  (CM) 

•  Decision  Analysis  and  Resolution  (DAR) 

•  Measurement  and  Analysis  (MA) 

•  Process  and  Product  Quality  Assurance  (PPQA) 

Basic  Support  Process  Areas _ 

The  Basic  Support  process  areas  address  fundamental  support  functions 
that  are  used  by  all  process  areas.  Although  all  Support  process  areas  rely 
on  the  other  process  areas  for  input,  the  Basic  Support  process  areas 
provide  support  functions  that  also  help  implement  several  generic 
practices. 

Figure  4.6  provides  a  bird’s-eye  view  of  the  interactions  among  the  Basic 
Support  process  areas  and  with  all  other  process  areas. 


CM  =  Configuration  Management 
MA  =  Measurement  and  Analysis 
PPQA  =  Process  and  Product  Quaiity  Assurance 

Figure  4.6:  Basic  Support  Process  Areas 

The  Measurement  and  Analysis  process  area  supports  all  process  areas  by 
providing  specific  practices  that  guide  projects  and  organizations  in  aligning 
measurement  needs  and  objectives  with  a  measurement  approach  that  is 
used  to  support  management  information  needs.  The  results  can  be  used  in 
making  informed  decisions  and  taking  appropriate  corrective  actions. 

The  Process  and  Product  Quality  Assurance  process  area  supports  all 
process  areas  by  providing  specific  practices  for  objectively  evaluating 
performed  processes,  work  products,  and  services  against  the  applicable 
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process  descriptions,  standards,  and  procedures,  and  ensuring  that  any 
issues  arising  from  these  reviews  are  addressed. 

Process  and  Product  Quality  Assurance  supports  the  delivery  of  high 
quality  products  and  services  by  providing  the  project  staff  and  all  levels  of 
management  with  appropriate  visibility  into,  and  feedback  on,  the  processes 
and  associated  work  products  throughout  the  life  of  the  project. 

The  Configuration  Management  process  area  supports  all  process  areas  by 
establishing  and  maintaining  the  integrity  of  work  products  using 
configuration  identification,  configuration  control,  configuration  status 
accounting,  and  configuration  audits.  The  work  products  placed  under 
configuration  management  include  the  products  that  are  delivered  to  the 
customer,  designated  internal  work  products,  acquired  products,  tools,  and 
other  items  that  are  used  in  creating  and  describing  these  work  products. 

Examples  of  work  products  that  can  be  placed  under  configuration 
management  include  plans,  process  descriptions,  requirements,  design 
data,  drawings,  product  specifications,  code,  compilers,  product  data  files, 
and  product  technical  publications. 

Advanced  Support  Process  Areas _ 

The  Advanced  Support  process  areas  provide  the  projects  and  organization 
with  an  improved  support  capability.  Each  of  these  process  areas  relies  on 
specific  inputs  or  practices  from  other  process  areas. 

Figure  4.7  provides  a  bird’s-eye  view  of  the  interactions  among  the 
Advanced  Support  process  areas  and  with  all  other  process  areas. 
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Using  the  Causal  Analysis  and  Resolution  process  area,  project  members 
identify  causes  of  selected  outcomes  and  take  action  to  prevent  negative 
outcomes  from  occurring  in  the  future  or  to  leverage  positive  outcomes. 
While  the  project’s  defined  processes  are  the  initial  targets  for  root  cause 
analysis  and  action  plans,  effective  process  changes  can  result  in  process 
improvement  proposals  submitted  to  the  organization’s  set  of  standard 
processes. 

The  Decision  Analysis  and  Resolution  process  area  supports  all  the 
process  areas  by  determining  which  issues  should  be  subjected  to  a  formal 
evaluation  process  and  then  applying  a  formal  evaluation  process  to  them. 
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5  Using  CMMI  Models 


The  complexity  of  products  today  demands  an  integrated  view  of  how 
organizations  do  business.  CMMI  can  reduce  the  cost  of  process 
improvement  across  enterprises  that  depend  on  multiple  functions  or 
groups  to  achieve  their  objectives. 

To  achieve  this  integrated  view,  the  CMMI  Framework  includes  common 
terminology,  common  model  components,  common  appraisal  methods,  and 
common  training  materials.  This  chapter  describes  how  organizations  can 
use  the  CMMI  Product  Suite  not  only  to  improve  their  quality,  reduce  their 
costs,  and  optimize  their  schedules,  but  also  to  gauge  how  well  their 
process  improvement  program  is  working. 


Adopting  CMMI 


Research  has  shown  that  the  most  powerful  initial  step  to  process 
improvement  is  to  build  organizational  support  through  strong  senior 
management  sponsorship.  To  gain  the  sponsorship  of  senior  management, 
it  is  often  beneficial  to  expose  them  to  the  performance  results  experienced 
by  others  who  have  used  CMMI  to  improve  their  processes  [Gibson  2006]. 

For  more  information  about  CMMI  performance  results,  see  the  SEI  website 
at  http://www.sei.cmu.edu/cmmi/research/results/. 

The  senior  manager,  once  committed  as  the  process  improvement  sponsor, 
must  be  actively  involved  in  the  CMMI-based  process  improvement  effort. 
Activities  performed  by  the  senior  management  sponsor  include  but  are  not 
limited  to  the  following: 

•  Influence  the  organization  to  adopt  CMMI 

•  Choose  the  best  people  to  manage  the  process  improvement  effort 

•  Monitor  the  process  improvement  effort  personally 

•  Be  a  visible  advocate  and  spokesperson  for  the  process  improvement 
effort 

•  Ensure  that  adequate  resources  are  available  to  enable  the  process 
improvement  effort  to  be  successful 

Given  sufficient  senior  management  sponsorship,  the  next  step  is 
establishing  a  strong,  technically  competent  process  group  that  represents 
relevant  stakeholders  to  guide  process  improvement  efforts  [Ahern  2008, 
Dymond  2005]. 

For  an  organization  with  a  mission  to  develop  software-intensive  systems, 
the  process  group  might  include  those  who  represent  different  disciplines 
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across  the  organization  and  other  selected  members  based  on  the  business 
needs  driving  improvement.  For  example,  a  systems  administrator  may 
focus  on  information  technology  support,  whereas  a  marketing 
representative  may  focus  on  integrating  customers’  needs.  Both  members 
could  make  powerful  contributions  to  the  process  group. 

Once  your  organization  decides  to  adopt  CMMI,  planning  can  begin  with  an 
improvement  approach  such  as  the  IDEAL®^  (Initiating,  Diagnosing, 
Establishing,  Acting,  and  Learning)  model  [McFeeley  1996].  For  more 
information  about  the  IDEAL  model,  see  the  SEI  website  at 
http://www.sei.cmu.edu/library/abstracts/reports/96hb001  .cfm. 


Your  Process  Improvement  Program 


Use  the  CMMI  Product  Suite  to  help  establish  your  organization’s  process 
improvement  program.  Using  the  product  suite  for  this  purpose  can  be  a 
relatively  informal  process  that  involves  understanding  and  applying  CMMI 
best  practices  to  your  organization.  Or,  it  can  be  a  formal  process  that 
involves  extensive  training,  creation  of  a  process  improvement 
infrastructure,  appraisals,  and  more. 


Selections  that  Influence  Your  Program 


You  must  make  three  selections  to  apply  CMMI  to  your  organization  for 
process  improvement: 

1.  Select  a  part  of  the  organization. 

2.  Select  a  model. 

3.  Select  a  representation. 

Selecting  the  projects  to  be  involved  in  your  process  improvement  program 
is  critical.  If  you  select  a  group  that  is  too  large,  it  may  be  too  much  for  the 
initial  improvement  effort.  The  selection  should  also  consider  organizational, 
product,  and  work  homogeneity  (i.e.,  whether  the  group’s  members  all  are 
experts  in  the  same  discipline,  whether  they  all  work  on  the  same  product 
or  business  line,  and  so  on). 

Selecting  an  appropriate  model  is  also  essential  to  a  successful  process 
improvement  program.  The  CMMI-DEV  model  focuses  on  activities  for 
developing  quality  products  and  services.  The  CMMI-ACQ  model  focuses 
on  activities  for  initiating  and  managing  the  acquisition  of  products  and 
services.  The  CMMI-SVC  model  focuses  on  activities  for  providing  quality 
services  to  the  customer  and  end  users.  When  selecting  a  model, 
appropriate  consideration  should  be  given  to  the  primary  focus  of  the 
organization  and  projects,  as  well  as  to  the  processes  necessary  to  satisfy 
business  objectives.  The  lifecycle  processes  (e.g.,  conception,  design, 
manufacture,  deployment,  operations,  maintenance,  disposal)  on  which  an 
organization  concentrates  should  also  be  considered  when  selecting  an 
appropriate  model. 
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Select  the  representation  (capability  or  maturity  levels)  that  fits  your  concept 
of  process  improvement.  Regardless  of  which  you  choose,  you  can  select 
nearly  any  process  area  or  group  of  process  areas  to  guide  improvement, 
although  dependencies  among  process  areas  should  be  considered  when 
making  such  a  selection. 

As  process  improvement  plans  and  activities  progress,  other  important 
selections  must  be  made,  including  whether  to  use  an  appraisal,  which 
appraisal  method  should  be  used,  which  projects  should  be  appraised,  how 
training  for  staff  should  be  secured,  and  which  staff  members  should  be 
trained. 


CMMI  Models 


CMMI  models  describe  best  practices  that  organizations  have  found  to  be 
productive  and  useful  to  achieving  their  business  objectives.  Regardless  of 
your  organization,  you  must  use  professional  judgment  when  interpreting 
CMMI  best  practices  for  your  situation,  needs,  and  business  objectives. 

This  use  of  judgment  is  reinforced  when  you  see  words  such  as  “adequate,” 
“appropriate,”  or  “as  needed”  in  a  goal  or  practice.  These  words  are  used 
for  activities  that  may  not  be  equally  relevant  in  all  situations.  Interpret  these 
goals  and  practices  in  ways  that  work  for  your  organization. 

Although  process  areas  depict  the  characteristics  of  an  organization 
committed  to  process  improvement,  you  must  interpret  the  process  areas 
using  an  in-depth  knowledge  of  CMMI,  your  organization,  the  business 
environment,  and  the  specific  circumstances  involved. 

As  you  begin  using  a  CMMI  model  to  improve  your  organization’s 
processes,  map  your  real  world  processes  to  CMMI  process  areas.  This 
mapping  enables  you  to  initially  judge  and  later  track  your  organization’s 
level  of  conformance  to  the  CMMI  model  you  are  using  and  to  identify 
opportunities  for  improvement. 

To  interpret  practices,  it  is  important  to  consider  the  overall  context  in  which 
these  practices  are  used  and  to  determine  how  well  the  practices  satisfy  the 
goals  of  a  process  area  in  that  context.  CMMI  models  do  not  prescribe  nor 
imply  processes  that  are  right  for  any  organization  or  project.  Instead, 

CMMI  describes  minimal  criteria  necessary  to  plan  and  implement 
processes  selected  by  the  organization  for  improvement  based  on  business 
objectives. 

CMMI  practices  purposely  use  nonspecific  phrases  such  as  “relevant 
stakeholders,”  “as  appropriate,”  and  “as  necessary”  to  accommodate  the 
needs  of  different  organizations  and  projects.  The  specific  needs  of  a 
project  can  also  differ  at  various  points  in  its  life. 
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Interpreting  CMMI  When  Using  Agiie  Approaches 


CMMI  practices  are  designed  to  provide  value  across  a  range  of  different 
situations  and  thus  are  stated  in  general  terms.  Because  CMMI  does  not 
endorse  any  particular  approach  to  development,  little  information  that  is 
approach-specific  is  provided.  Therefore,  those  who  don’t  have  prior 
experience  implementing  CMMI  in  situations  similar  to  the  one  they  are  now 
in  may  find  interpretation  non-intuitive. 

To  help  those  who  use  Agile  methods  to  interpret  CMMI  practices  in  their 
environments,  notes  have  been  added  to  selected  process  areas.  These 
notes  are  added,  usually  in  the  introductory  notes,  to  the  following  process 
areas  in  CMMI-DEV:  CM,  PI,  PMC,  PP,  PPQA,  RD,  REQM,  RSKM,  TS,  and 
VER. 

All  of  the  notes  begin  with  the  words,  “In  Agile  environments”  and  are  in 
example  boxes  to  help  you  to  easily  recognize  them  and  remind  you  that 
these  notes  are  examples  of  how  to  interpret  practices  and  therefore  are 
neither  necessary  nor  sufficient  for  implementing  the  process  area. 

Multiple  Agile  approaches  exist.  The  phrases  “Agile  environment”  and 
“Agile  method”  are  shorthand  for  any  development  or  management 
approach  that  adheres  to  the  Manifesto  for  Agile  Development  [Beck  2001]. 

Such  approaches  are  characterized  by  the  following: 

•  Direct  involvement  of  the  customer  in  product  development 

•  Use  of  multiple  development  iterations  to  learn  about  and  evolve 
the  product 

•  Customer  willingness  to  share  in  the  responsibility  for  decisions  and 
risk 

Many  development  and  management  approaches  can  share  one  or  more  of 
these  characteristics  and  yet  not  be  called  “Agile.”  For  example,  some 
teams  are  arguably  “Agile”  even  though  the  term  Agile  is  not  used.  Even  if 
you  are  not  using  an  Agile  approach,  you  might  still  find  value  in  these 
notes. 

Be  cautious  when  using  these  notes.  Your  ultimate  interpretation  of  the 
process  area  should  fit  the  specifics  of  your  situation,  including  your 
organization’s  business,  project,  work  group,  or  team  objectives,  while  fully 
meeting  a  CMMI  process  area’s  goals  and  practices.  As  mentioned  earlier, 
the  notes  should  be  taken  as  examples  and  are  neither  necessary  nor 
sufficient  to  implementing  the  process  area. 

Some  general  background  and  motivation  for  the  guidance  given  on  Agile 
development  approaches  are  found  in  the  SEI  technical  note  CMMI  or 
Agile:  Why  Not  Embrace  Both!  [Glazer  2008]. 
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Using  CMMI  Appraisals 


Many  organizations  find  value  in  measuring  their  progress  by  conducting  an 
appraisal  and  earning  a  maturity  level  rating  or  a  capability  level 
achievement  profile.  These  types  of  appraisals  are  typically  conducted  for 
one  or  more  of  the  following  reasons: 

•  To  determine  how  well  the  organization’s  processes  compare  to  CMMI 
best  practices  and  identify  areas  where  improvement  can  be  made 

•  To  inform  external  customers  and  suppliers  about  how  well  the 
organization’s  processes  compare  to  CMMI  best  practices 

•  To  meet  the  contractual  requirements  of  one  or  more  customers 

Appraisals  of  organizations  using  a  CMMI  model  must  conform  to  the 
requirements  defined  in  the  Appraisal  Requirements  for  CMMI  (ARC)  [SEI 
2011b]  document.  Appraisals  focus  on  identifying  improvement 
opportunities  and  comparing  the  organization’s  processes  to  CMMI  best 
practices. 

Appraisal  teams  use  a  CMMI  model  and  ARC-conformant  appraisal  method 
to  guide  their  evaluation  of  the  organization  and  their  reporting  of 
conclusions.  The  appraisal  results  are  used  (e.g.,  by  a  process  group)  to 
plan  improvements  for  the  organization. 


Appraisal  Requirements  for  CMMI 


The  Appraisal  Requirements  for  CMMI  (ARC)  document  describes  the 
requirements  for  several  types  of  appraisals.  A  full  benchmarking  appraisal 
is  defined  as  a  Class  A  appraisal  method.  Less  formal  methods  are  defined 
as  Class  B  or  Class  C  methods.  The  ARC  document  was  designed  to  help 
improve  consistency  across  appraisal  methods  and  to  help  appraisal 
method  developers,  sponsors,  and  users  understand  the  tradeoffs 
associated  with  various  methods. 

Depending  on  the  purpose  of  the  appraisal  and  the  nature  of  the 
circumstances,  one  class  may  be  preferred  over  the  others.  Sometimes  self 
assessments,  initial  appraisals,  quick-look  or  mini  appraisals,  or  external 
appraisals  are  appropriate;  at  other  times  a  formal  benchmarking  appraisal 
is  appropriate. 

A  particular  appraisal  method  is  declared  an  ARC  Class  A,  B,  or  C 
appraisal  method  based  on  the  sets  of  ARC  requirements  that  the  method 
developer  addressed  when  designing  the  method. 

More  information  about  the  ARC  is  available  on  the  SEI  website  at 
http://www.sei.cmu.edu/cmmi/tools/appraisals/. 


SCAMPI  Appraisal  Methods 


The  SCAMPI  A  appraisal  method  is  the  generally  accepted  method  used  for 
conducting  ARC  Class  A  appraisals  using  CMMI  models.  The  SCAMPI  A 
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Method  Definition  Document  (MDD)  defines  rules  for  ensuring  the 
consistency  of  SCAMPI  A  appraisal  ratings  [SEI  2011a].  For  benchmarking 
against  other  organizations,  appraisals  must  ensure  consistent  ratings.  The 
achievement  of  a  specific  maturity  level  or  the  satisfaction  of  a  process  area 
must  mean  the  same  thing  for  different  appraised  organizations. 

The  SCAMPI  family  of  appraisals  includes  Class  A,  B,  and  C  appraisal 
methods.  The  SCAMPI  A  appraisal  method  is  the  officially  recognized  and 
most  rigorous  method.  It  is  the  only  method  that  can  result  in  benchmark 
quality  ratings.  SCAMPI  B  and  C  appraisal  methods  provide  organizations 
with  improvement  information  that  is  less  formal  than  the  results  of  a 
SCAMPI  A  appraisal,  but  nonetheless  helps  the  organization  to  identify 
improvement  opportunities. 

More  information  about  SCAMPI  methods  is  available  on  the  SEI  website  at 
http://www.sei.cmu.edu/cmmi/tools/appraisals/. 


Appraisal  Considerations 


Choices  that  affect  a  CMMI-based  appraisal  include  the  following: 

•  CMMI  model 

•  Appraisal  scope,  including  the  organizational  unit  to  be  appraised,  the 
CMMI  process  areas  to  be  investigated,  and  the  maturity  level  or 
capability  levels  to  be  appraised 

•  Appraisal  method 

•  Appraisal  team  leader  and  team  members 

•  Appraisal  participants  selected  from  the  appraisal  entities  to  be 
interviewed 

•  Appraisal  outputs  (e.g.,  ratings,  instantiation-specific  findings) 

•  Appraisal  constraints  (e.g.,  time  spent  on  site) 

The  SCAMPI  MDD  allows  the  selection  of  predefined  options  for  use  in  an 
appraisal.  These  appraisal  options  are  designed  to  help  organizations  align 
CMMI  with  their  business  needs  and  objectives. 

CMMI  appraisal  plans  and  results  should  always  include  a  description  of  the 
appraisal  options,  model  scope,  and  organizational  scope  selected.  This 
documentation  confirms  whether  an  appraisal  meets  the  requirements  for 
benchmarking. 

For  organizations  that  wish  to  appraise  multiple  functions  or  groups,  the 
integrated  approach  of  CMMI  enables  some  economy  of  scale  in  model  and 
appraisal  training.  One  appraisal  method  can  provide  separate  or  combined 
results  for  multiple  functions. 

The  following  appraisal  principles  for  CMMI  are  the  same  as  those 
principles  used  in  appraisals  for  other  process  improvement  models: 
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•  Senior  management  sponsorship^” 

•  A  focus  on  the  organization’s  business  objectives 

•  Confidentiality  for  interviewees 

•  Use  of  a  documented  appraisal  method 

•  Use  of  a  process  reference  model  (e.g.,  a  CMMI  model) 

•  A  collaborative  team  approach 

•  A  focus  on  actions  for  process  improvement 


CMMI  Related  Training 


Whether  your  organization  is  new  to  process  improvement  or  is  already 
familiar  with  process  improvement  models,  training  is  a  key  element  in  the 
ability  of  organizations  to  adopt  CMMI.  An  initial  set  of  courses  is  provided 
by  the  SEI  and  its  Partner  Network,  but  your  organization  may  wish  to 
supplement  these  courses  with  its  own  instruction.  This  approach  allows 
your  organization  to  focus  on  areas  that  provide  the  greatest  business 
value. 

The  SEI  and  its  Partner  Network  offer  the  introductory  course.  Introduction 
to  CMMI  for  Development  The  SEI  also  offers  advanced  training  to  those 
who  plan  to  become  more  deeply  involved  in  CMMI  adoption  or  appraisal — 
for  example,  those  who  will  guide  improvement  as  part  of  a  process  group, 
those  who  will  lead  SCAMPI  appraisals,  and  those  who  will  teach  the 
Introduction  to  CMMI  for  Development  course. 

Current  information  about  CMMI  related  training  is  available  on  the  SEI 
website  at  http://www.sei.cmu.edu/traininq/. 


Experience  has  shown  that  the  most  critical  factor  influencing  successful  process  improvement  and  appraisals  is  senior 
management  sponsorship. 
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Part  Two: 

Generic  Goais  and  Generic  Practices, 
and  the  Process  Areas 
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GENERIC  GOALS  AND  GENERIC  PRACTICES 


Overview 


This  section  describes  in  detail  all  the  generic  goals  and  generic  practices 
of  CMMI — model  components  that  directly  address  process 
institutionalization.  As  you  address  each  process  area,  refer  to  this  section 
for  the  details  of  all  generic  practices. 

Generic  practice  elaborations  appear  after  generic  practices  to  provide 
guidance  on  how  the  generic  practice  can  be  applied  uniquely  to  process 
areas. 


Process  Institutionalization 


Institutionalization  is  an  important  concept  in  process  improvement.  When 
mentioned  in  the  generic  goal  and  generic  practice  descriptions, 
institutionalization  implies  that  the  process  is  ingrained  in  the  way  the  work 
is  performed  and  there  is  commitment  and  consistency  to  performing  (i.e., 
executing)  the  process. 

An  institutionalized  process  is  more  likely  to  be  retained  during  times  of 
stress.  When  the  requirements  and  objectives  for  the  process  change, 
however,  the  implementation  of  the  process  may  also  need  to  change  to 
ensure  that  it  remains  effective.  The  generic  practices  describe  activities 
that  address  these  aspects  of  institutionalization. 

The  degree  of  institutionalization  is  embodied  in  the  generic  goals  and 
expressed  in  the  names  of  the  processes  associated  with  each  goal  as 
indicated  in  Table  6.1 . 


Table  6. 1  Generic  Goals  and  Process  Names 


Generic  Goal 

Progression  of  Processes 

GG  1 

Performed  process 

GG2 

Managed  process 

GG3 

Defined  process 

The  progression  of  process  institutionalization  is  characterized  in  the 
following  descriptions  of  each  process. 

Performed  Process 

A  performed  process  is  a  process  that  accomplishes  the  work  necessary  to 
satisfy  the  specific  goals  of  a  process  area. 
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Managed  Process _ 

A  managed  process  is  a  performed  process  that  is  planned  and  executed  in 
accordance  with  policy;  employs  skilled  people  having  adequate  resources 
to  produce  controlled  outputs;  involves  relevant  stakeholders;  is  monitored, 
controlled,  and  reviewed;  and  is  evaluated  for  adherence  to  its  process 
description. 

The  process  can  be  instantiated  by  a  project,  group,  or  organizational 
function.  Management  of  the  process  is  concerned  with  institutionalization 
and  the  achievement  of  other  specific  objectives  established  for  the 
process,  such  as  cost,  schedule,  and  quality  objectives.  The  control 
provided  by  a  managed  process  helps  to  ensure  that  the  established 
process  is  retained  during  times  of  stress. 

The  requirements  and  objectives  for  the  process  are  established  by  the 
organization.  The  status  of  the  work  products  and  services  are  visible  to 
management  at  defined  points  (e.g.,  at  major  milestones,  on  completion  of 
major  tasks).  Commitments  are  established  among  those  who  perform  the 
work  and  the  relevant  stakeholders  and  are  revised  as  necessary.  Work 
products  are  reviewed  with  relevant  stakeholders  and  are  controlled.  The 
work  products  and  services  satisfy  their  specified  requirements. 

A  critical  distinction  between  a  performed  process  and  a  managed  process 
is  the  extent  to  which  the  process  is  managed.  A  managed  process  is 
planned  (the  plan  can  be  part  of  a  more  encompassing  plan)  and  the 
execution  of  the  process  is  managed  against  the  plan.  Corrective  actions 
are  taken  when  the  actual  results  and  execution  deviate  significantly  from 
the  plan.  A  managed  process  achieves  the  objectives  of  the  plan  and  is 
institutionalized  for  consistent  execution. 

Defined  Process 

A  defined  process  is  a  managed  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes  according  to  the  organization’s 
tailoring  guidelines;  has  a  maintained  process  description;  and  contributes 
process  related  experiences  to  the  organizational  process  assets. 

Organizational  process  assets  are  artifacts  that  relate  to  describing, 
implementing,  and  improving  processes.  These  artifacts  are  assets 
because  they  are  developed  or  acquired  to  meet  the  business  objectives  of 
the  organization  and  they  represent  investments  by  the  organization  that 
are  expected  to  provide  current  and  future  business  value. 

The  organization’s  set  of  standard  processes,  which  are  the  basis  of  the 
defined  process,  are  established  and  improved  over  time.  Standard 
processes  describe  the  fundamental  process  elements  that  are  expected  in 
the  defined  processes.  Standard  processes  also  describe  the  relationships 
(e.g.,  the  ordering,  the  interfaces)  among  these  process  elements.  The 
organization-level  infrastructure  to  support  current  and  future  use  of  the 
organization’s  set  of  standard  processes  is  established  and  improved  over 
time.  (See  the  definition  of  “standard  process”  in  the  glossary.) 
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A  project’s  defined  process  provides  a  basis  for  planning,  performing,  and 
improving  the  project’s  tasks  and  activities.  A  project  can  have  more  than 
one  defined  process  (e.g.,  one  for  developing  the  product  and  another  for 
testing  the  product). 

A  defined  process  clearly  states  the  following: 

•  Purpose 

•  Inputs 

•  Entry  criteria 

•  Activities 

•  Roles 

•  Measures 

•  Verification  steps 

•  Outputs 

•  Exit  criteria 

A  critical  distinction  between  a  managed  process  and  a  defined  process  is 
the  scope  of  application  of  the  process  descriptions,  standards,  and 
procedures.  For  a  managed  process,  the  process  descriptions,  standards, 
and  procedures  are  applicable  to  a  particular  project,  group,  or 
organizational  function.  As  a  result,  the  managed  processes  of  two  projects 
in  one  organization  can  be  different. 

Another  critical  distinction  is  that  a  defined  process  is  described  in  more 
detail  and  is  performed  more  rigorously  than  a  managed  process.  This 
distinction  means  that  improvement  information  is  easier  to  understand, 
analyze,  and  use.  Finally,  management  of  the  defined  process  is  based  on 
the  additional  insight  provided  by  an  understanding  of  the  interrelationships 
of  the  process  activities  and  detailed  measures  of  the  process,  its  work 
products,  and  its  services. 

Relationships  Among  Processes 

The  generic  goals  evolve  so  that  each  goal  provides  a  foundation  for  the 
next.  Therefore,  the  following  conclusions  can  be  made: 

•  A  managed  process  is  a  performed  process. 

•  A  defined  process  is  a  managed  process. 

Thus,  applied  sequentially  and  in  order,  the  generic  goals  describe  a 
process  that  is  increasingly  institutionalized  from  a  performed  process  to  a 
defined  process. 

Achieving  GG  1  for  a  process  area  is  equivalent  to  saying  you  achieve  the 
specific  goals  of  the  process  area. 

Achieving  GG  2  for  a  process  area  is  equivalent  to  saying  you  manage  the 
execution  of  processes  associated  with  the  process  area.  There  is  a  policy 
that  indicates  you  will  perform  the  process.  There  is  a  plan  for  performing  it. 
There  are  resources  provided,  responsibilities  assigned,  training  on  howto 
perform  it,  selected  work  products  from  performing  the  process  are 


Generic  Goals  and  Generic  Practices 


67 


CMMI  for  Development,  Version  1.3 


controlled,  and  so  on.  In  other  words,  the  process  is  planned  and  monitored 
just  like  any  project  or  support  activity. 

Achieving  GG  3  for  a  process  area  is  equivalent  to  saying  that  an 
organizational  standard  process  exists  that  can  be  tailored  to  result  in  the 
process  you  will  use.  Tailoring  might  result  in  making  no  changes  to  the 
standard  process.  In  other  words,  the  process  used  and  the  standard 
process  can  be  identical.  Using  the  standard  process  “as  is”  is  tailoring 
because  the  choice  is  made  that  no  modification  is  required. 

Each  process  area  describes  multiple  activities,  some  of  which  are 
repeatedly  performed.  You  may  need  to  tailor  the  way  one  of  these 
activities  is  performed  to  account  for  new  capabilities  or  circumstances.  For 
example,  you  may  have  a  standard  for  developing  or  obtaining 
organizational  training  that  does  not  consider  web-based  training.  When 
preparing  to  develop  or  obtain  a  web-based  course,  you  may  need  to  tailor 
the  standard  process  to  account  for  the  particular  challenges  and  benefits 
of  web-based  training. 


Generic  Goals  and  Generic  Practices 


This  section  describes  all  of  the  generic  goals  and  generic  practices,  as  well 
as  their  associated  subpractices,  notes,  examples,  and  references.  The 
generic  goals  are  organized  in  numerical  order,  GG  1  through  GG  3.  The 
generic  practices  are  also  organized  in  numerical  order  under  the  generic 
goal  they  support. 

GG  1 _ Achieve  Specific  Goals _ 

The  specific  goais  of  the  process  area  are  supported  by  the  process  by 
transforming  identifiabie  input  work  products  into  identifiabie  output  work 
products. 


GP  1 .1  Perform  Specific  Practices 

Perform  the  specific  practices  of  the  process  area  to  deveiop  work 
products  and  provide  services  to  achieve  the  specific  goais  of  the 
process  area. 

The  purpose  of  this  generic  practice  is  to  produce  the  work  products  and 
deliver  the  services  that  are  expected  by  performing  (i.e.,  executing)  the 
process.  These  practices  can  be  done  informally  without  following  a 
documented  process  description  or  plan.  The  rigor  with  which  these 
practices  are  performed  depends  on  the  individuals  managing  and 
performing  the  work  and  can  vary  considerably. 
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GG  2 _ Institutionalize  a  Managed  Process _ 

The  process  is  institutionalized  as  a  managed  process. 

GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  process. 

The  purpose  of  this  generic  practice  is  to  define  the  organizational 
expectations  for  the  process  and  make  these  expectations  visible  to  those 
members  of  the  organization  who  are  affected.  In  general,  senior 
management  is  responsible  for  establishing  and  communicating  guiding 
principles,  direction,  and  expectations  for  the  organization. 

Not  all  direction  from  senior  management  will  bear  the  label  “policy.”  The 
existence  of  appropriate  organizational  direction  is  the  expectation  of  this 
generic  practice,  regardless  of  what  it  is  called  or  how  it  is  imparted. 

CAR  Elaboration 

This  policy  establishes  organizational  expectations  for  identifying  and 
systematically  addressing  causal  analysis  of  selected  outcomes. 

CM  Elaboration 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  baselines,  tracking  and  controlling  changes  to  work  products 
(under  configuration  management),  and  establishing  and  maintaining 
integrity  of  the  baselines. 

DAR  Elaboration 

This  policy  establishes  organizational  expectations  for  selectively  analyzing 
possible  decisions  using  a  formal  evaluation  process  that  evaluates 
identified  alternatives  against  established  criteria.  The  policy  should  also 
provide  guidance  on  which  decisions  require  a  formal  evaluation  process. 

IPM  Elaboration 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  the  project’s  defined  process  from  project  startup  through  the 
life  of  the  project,  using  the  project’s  defined  process  in  managing  the 
project,  and  coordinating  and  collaborating  with  relevant  stakeholders. 

MA  Elaboration 

This  policy  establishes  organizational  expectations  for  aligning 
measurement  objectives  and  activities  with  identified  information  needs  and 
project,  organizational,  or  business  objectives  and  for  providing 
measurement  results. 

OPD  Elaboration 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  a  set  of  standard  processes  for  use  by  the  organization,  making 
organizational  process  assets  available  across  the  organization,  and 
establishing  rules  and  guidelines  for  teams. 
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OPF  Elaboration 

This  policy  establishes  organizational  expectations  for  determining  process 
improvement  opportunities  for  the  processes  being  used  and  for  planning, 
implementing,  and  deploying  process  improvements  across  the 
organization. 

0PM  Elaboration 

This  policy  establishes  organizational  expectations  for  analyzing  the 
organization’s  business  performance  using  statistical  and  other  quantitative 
techniques  to  determine  performance  shortfalls,  and  identifying  and 
deploying  process  and  technology  improvements  that  contribute  to  meeting 
quality  and  process  performance  objectives. 

OPP  Elaboration 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  process  performance  baselines  and  process  performance 
models  for  the  organization’s  set  of  standard  processes. 

OT  Elaboration 

This  policy  establishes  organizational  expectations  for  identifying  the 
strategic  training  needs  of  the  organization  and  providing  that  training. 

PI  Elaboration 

This  policy  establishes  organizational  expectations  for  developing  product 
integration  strategies,  procedures,  and  an  environment;  ensuring  interface 
compatibility  among  product  components;  assembling  the  product 
components;  and  delivering  the  product  and  product  components. 

PMC  Elaboration 

This  policy  establishes  organizational  expectations  for  monitoring  project 
progress  and  performance  against  the  project  plan  and  managing  corrective 
action  to  closure  when  actual  or  results  deviate  significantly  from  the  plan. 

PP  Elaboration 

This  policy  establishes  organizational  expectations  for  estimating  the 
planning  parameters,  making  internal  and  external  commitments,  and 
developing  the  plan  for  managing  the  project. 

PPQA  Elaboration 

This  policy  establishes  organizational  expectations  for  objectively 
evaluating  whether  processes  and  associated  work  products  adhere  to 
applicable  process  descriptions,  standards,  and  procedures;  and  ensuring 
that  noncompliance  is  addressed. 

This  policy  also  establishes  organizational  expectations  for  process  and 
product  quality  assurance  being  in  place  for  all  projects.  Process  and 
product  quality  assurance  must  possess  sufficient  independence  from 
project  management  to  provide  objectivity  in  identifying  and  reporting 
noncompliance  issues. 
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QPM  Elaboration 

This  policy  establishes  organizational  expectations  for  using  statistical  and 
other  quantitative  techniques  and  historical  data  when:  establishing  quality 
and  process  performance  objectives,  composing  the  project’s  defined 
process,  selecting  subprocess  attributes  critical  to  understanding  process 
performance,  monitoring  subprocess  and  project  performance,  and 
performing  root  cause  analysis  to  address  process  performance 
deficiencies.  In  particular,  this  policy  establishes  organizational 
expectations  for  use  of  process  performance  measures,  baselines,  and 
models. 

RD  Elaboration 

This  policy  establishes  organizational  expectations  for  collecting 
stakeholder  needs,  formulating  product  and  product  component 
requirements,  and  analyzing  and  validating  those  requirements. 

REQM  Elaboration 

This  policy  establishes  organizational  expectations  for  managing 
requirements  and  identifying  inconsistencies  between  the  requirements  and 
the  project  plans  and  work  products. 

RSKM  Elaboration 

This  policy  establishes  organizational  expectations  for  defining  a  risk 
management  strategy  and  identifying,  analyzing,  and  mitigating  risks. 

SAM  Elaboration 

This  policy  establishes  organizational  expectations  for  establishing, 
maintaining,  and  satisfying  supplier  agreements. 

TS  Elaboration 

This  policy  establishes  organizational  expectations  for  addressing  the 
iterative  cycle  in  which  product  or  product  component  solutions  are 
selected,  designs  are  developed,  and  designs  are  implemented. 

VAL  Elaboration 

This  policy  establishes  organizational  expectations  for  selecting  products 
and  product  components  for  validation;  for  selecting  validation  methods; 
and  for  establishing  and  maintaining  validation  procedures,  criteria,  and 
environments  that  ensure  the  products  and  product  components  satisfy  end 
user  needs  in  their  intended  operating  environment. 

VER  Elaboration 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  verification  methods,  procedures,  criteria,  and  the  verification 
environment,  as  well  as  for  performing  peer  reviews  and  verifying  selected 
work  products. 
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GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  process. 

The  purpose  of  this  generic  practice  is  to  determine  what  is  needed  to 
perform  the  process  and  to  achieve  the  established  objectives,  to  prepare  a 
plan  for  performing  the  process,  to  prepare  a  process  description,  and  to 
get  agreement  on  the  plan  from  relevant  stakeholders. 

The  practical  implications  of  applying  a  generic  practice  vary  for  each 
process  area. 

;  For  example,  the  planning  described  by  this  generic  practice  as  applied  to  the  Project 
i  Monitoring  and  Control  process  area  can  be  carried  out  in  full  by  the  processes  associated 
I  with  the  Project  Planning  process  area.  However,  this  generic  practice,  when  applied  to  the 
;  Project  Planning  process  area,  sets  an  expectation  that  the  project  planning  process  itself 
I  be  planned. 


Therefore,  this  generic  practice  can  either  reinforce  expectations  set 
elsewhere  in  CMMI  or  set  new  expectations  that  should  be  addressed. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  and  maintaining  plans  that  define  project  activities. 

Establishing  a  plan  includes  documenting  the  plan  and  a  process 
description.  Maintaining  the  plan  includes  updating  it  to  reflect  corrective 

actions  or  changes  in  requirements  or  objectives. 

- - - - - 

I  The  plan  for  performing  the  process  typically  includes  the  following: 

I  •  Process  description 

;  •  Standards  and  requirements  for  the  work  products  and  services  of  the  process 

i  •  Specific  objectives  for  the  execution  of  the  process  and  its  results  (e.g.,  quality,  time 

:  scale,  cycle  time,  use  of  resources) 

I  •  Dependencies  among  the  activities,  work  products,  and  services  of  the  process 

;  •  Resources  (e.g.,  funding,  people,  tools)  needed  to  perform  the  process 

i  •  Assignment  of  responsibility  and  authority 

i  •  Training  needed  for  performing  and  supporting  the  process 

i  •  Work  products  to  be  controlled  and  the  level  of  control  to  be  applied 

I  •  Measurement  requirements  to  provide  insight  into  the  execution  of  the  process,  its  work 

;  products,  and  its  services 

i  •  Involvement  of  relevant  stakeholders 
;  •  Activities  for  monitoring  and  controlling  the  process 
i  •  Objective  evaluation  activities  of  the  process 
:  •  Management  review  activities  for  the  process  and  the  work  products 


Subpractices 

1 .  Define  and  document  the  plan  for  performing  the  process. 
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This  plan  can  be  a  stand-alone  document,  embedded  in  a  more  comprehensive 
document,  or  distributed  among  multiple  documents.  In  the  case  of  the  plan  being 
distributed  among  multiple  documents,  ensure  that  a  coherent  picture  of  who  does 
what  is  preserved.  Documents  can  be  hardcopy  or  softcopy. 

2.  Define  and  document  the  process  description. 

The  process  description,  which  includes  relevant  standards  and  procedures,  can  be 
included  as  part  of  the  plan  for  performing  the  process  or  can  be  included  in  the  plan 
by  reference. 

3.  Review  the  plan  with  relevant  stakeholders  and  get  their  agreement. 

This  review  of  the  plan  includes  reviewing  that  the  planned  process  satisfies  the 
applicable  policies,  plans,  requirements,  and  standards  to  provide  assurance  to 
relevant  stakeholders. 

4.  Revise  the  plan  as  necessary. 

CAR  Elaboration 

This  plan  for  performing  the  causal  analysis  and  resolution  process  can  be 
included  in  (or  referenced  by)  the  project  plan,  which  is  described  in  the 
Project  Planning  process  area.  This  plan  differs  from  the  action  proposals 
and  associated  action  plans  described  in  several  specific  practices  in  this 
process  area.  The  plan  called  for  in  this  generic  practice  would  address  the 
project’s  overall  causal  analysis  and  resolution  process  (perhaps  tailored 
from  a  standard  process  maintained  by  the  organization).  In  contrast,  the 
process  action  proposals  and  associated  action  items  address  the  activities 
needed  to  address  a  specific  root  cause  under  study. 

CM  Elaboration 

This  plan  for  performing  the  configuration  management  process  can  be 
included  in  (or  referenced  by)  the  project  plan,  which  is  described  in  the 
Project  Planning  process  area. 

DAR  Elaboration 

This  plan  for  performing  the  decision  analysis  and  resolution  process  can 
be  included  in  (or  referenced  by)  the  project  plan,  which  is  described  in  the 
Project  Planning  process  area. 

IPM  Elaboration 

This  plan  for  the  integrated  project  management  process  unites  the 
planning  for  the  project  planning  and  monitor  and  control  processes.  The 
planning  for  performing  the  planning  related  practices  in  Integrated  Project 
Management  is  addressed  as  part  of  planning  the  project  planning  process. 
This  plan  for  performing  the  monitor-and-control  related  practices  in 
Integrated  Project  Management  can  be  included  in  (or  referenced  by)  the 
project  plan,  which  is  described  in  the  Project  Planning  process  area. 
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MA  Elaboration 

This  plan  for  performing  the  measurement  and  analysis  process  can  be 
included  in  (or  referenced  by)  the  project  plan,  which  is  described  in  the 
Project  Planning  process  area. 

OPD  Elaboration 

This  plan  for  performing  the  organizational  process  definition  process  can 
be  part  of  (or  referenced  by)  the  organization’s  process  improvement  plan. 

OPF  Elaboration 

This  plan  for  performing  the  organizational  process  focus  process,  which  is 
often  called  “the  process  improvement  plan,”  differs  from  the  process  action 
plans  described  in  specific  practices  in  this  process  area.  The  plan  called 
for  in  this  generic  practice  addresses  the  comprehensive  planning  for  all  of 
the  specific  practices  in  this  process  area,  from  establishing  organizational 
process  needs  through  incorporating  process  related  experiences  into 
organizational  process  assets. 

0PM  Elaboration 

This  plan  for  performing  the  organizational  performance  management 
process  differs  from  the  deployment  plans  described  in  a  specific  practice  in 
this  process  area.  The  plan  called  for  in  this  generic  practice  addresses  the 
comprehensive  planning  for  all  of  the  specific  practices  in  this  process  area, 
from  maintaining  business  objectives  to  evaluating  improvement  effects.  In 
contrast,  the  deployment  plans  called  for  in  the  specific  practice  would 
address  the  planning  needed  for  the  deployment  of  selected  improvements. 

OPP  Elaboration 

This  plan  for  performing  the  organizational  process  performance  process 
can  be  included  in  (or  referenced  by)  the  organization’s  process 
improvement  plan,  which  is  described  in  the  Organizational  Process  Focus 
process  area.  Or  it  may  be  documented  in  a  separate  plan  that  describes 
only  the  plan  for  the  organizational  process  performance  process. 

OT  Elaboration 

This  plan  for  performing  the  organizational  training  process  differs  from  the 
tactical  plan  for  organizational  training  described  in  a  specific  practice  in  this 
process  area.  The  plan  called  for  in  this  generic  practice  addresses  the 
comprehensive  planning  for  all  of  the  specific  practices  in  this  process  area, 
from  establishing  strategic  training  needs  through  assessing  the 
effectiveness  of  organizational  training.  In  contrast,  the  organizational 
training  tactical  plan  called  for  in  the  specific  practice  of  this  process  area 
addresses  the  periodic  planning  for  the  delivery  of  training  offerings. 

PI  Elaboration 

This  plan  for  performing  the  product  integration  process  addresses  the 
comprehensive  planning  for  all  of  the  specific  practices  in  this  process  area, 
from  the  preparation  for  product  integration  all  the  way  through  to  the 
delivery  of  the  final  product. 
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This  plan  for  performing  the  product  integration  process  can  be  part  of  (or 
referenced  by)  the  project  plan  as  described  in  the  Project  Planning  process 
area. 

PMC  Elaboration 

This  plan  for  performing  the  project  monitoring  and  control  process  can  be 
part  of  (or  referenced  by)  the  project  plan,  as  described  in  the  Project 
Planning  process  area. 

PP  Elaboration 

Refer  to  Table  6.2  in  Generic  Goals  and  Generic  Practices  for  more 
information  about  the  relationship  between  generic  practice  2.2  and  the 
Project  Planning  process  area. 

PPQA  Elaboration 

This  plan  for  performing  the  process  and  product  quality  assurance  process 
can  be  included  in  (or  referenced  by)  the  project  plan,  which  is  described  in 
the  Project  Planning  process  area. 

QPM  Elaboration 

This  plan  for  performing  the  quantitative  project  management  process  can 
be  included  in  (or  referenced  by)  the  project  plan,  which  is  described  in  the 
Project  Planning  process  area. 

RD  Elaboration 

This  plan  for  performing  the  requirements  development  process  can  be  part 
of  (or  referenced  by)  the  project  plan  as  described  in  the  Project  Planning 
process  area. 

REQM  Elaboration 

This  plan  for  performing  the  requirements  management  process  can  be  part 
of  (or  referenced  by)  the  project  plan  as  described  in  the  Project  Planning 
process  area. 

RSKM  Elaboration 

This  plan  for  performing  the  risk  management  process  can  be  included  in 
(or  referenced  by)  the  project  plan,  which  is  described  in  the  Project 
Planning  process  area.  The  plan  called  for  in  this  generic  practice 
addresses  the  comprehensive  planning  for  all  of  the  specific  practices  in 
this  process  area.  In  particular,  this  plan  provides  the  overall  approach  for 
risk  mitigation,  but  is  distinct  from  mitigation  plans  (including  contingency 
plans)  for  specific  risks.  In  contrast,  the  risk  mitigation  plans  called  for  in  the 
specific  practices  of  this  process  area  addresses  more  focused  items  such 
as  the  levels  that  trigger  risk  handling  activities. 

SAM  Elaboration 

Portions  of  this  plan  for  performing  the  supplier  agreement  management 
process  can  be  part  of  (or  referenced  by)  the  project  plan  as  described  in 
the  Project  Planning  process  area.  Often,  however,  some  portions  of  the 
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plan  reside  outside  of  the  project  with  a  group  such  as  contract 
management. 

TS  Elaboration 

This  plan  for  performing  the  technical  solution  process  can  be  part  of  (or 
referenced  by)  the  project  plan  as  described  in  the  Project  Planning  process 
area. 

VAL  Elaboration 

This  plan  for  performing  the  validation  process  can  be  included  in  (or 
referenced  by)  the  project  plan,  which  is  described  in  the  Project  Planning 
process  area. 

VER  Elaboration 

This  plan  for  performing  the  verification  process  can  be  included  in  (or 
referenced  by)  the  project  plan,  which  is  described  in  the  Project  Planning 
process  area. 

GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  process, 
devetoping  the  work  products,  and  providing  the  services  of  the 
process. 

The  purpose  of  this  generic  practice  is  to  ensure  that  the  resources 
necessary  to  perform  the  process  as  defined  by  the  plan  are  available  when 
they  are  needed.  Resources  include  adequate  funding,  appropriate  physical 
facilities,  skilled  people,  and  appropriate  tools. 

The  interpretation  of  the  term  “adequate”  depends  on  many  factors  and  can 
change  over  time.  Inadequate  resources  may  be  addressed  by  increasing 
resources  or  by  removing  requirements,  constraints,  and  commitments. 

CAR  Elaboration 

:  Examples  of  resources  provided  include  the  following: 
i  •  Database  management  systems 

:  •  Process  modeling  tools 

I  •  Statistical  analysis  packages 


CM  Elaboration 

f - ................................................... 

I  Examples  of  resources  provided  include  the  following: 

I  •  Configuration  management  tools 

;  •  Data  management  tools 

i  •  Archiving  and  reproduction  tools 

;  •  Database  management  systems 
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DAR  Elaboration 

I  Examples  of  resources  provided  include  the  following: 
:  •  Simulators  and  modeling  tools 

I  •  Prototyping  tools 

;•  Tools  for  conducting  surveys 


I  PM  Elaboration 

;  Examples  of  resources  provided  include  the  following: 

I  •  Problem  tracking  and  trouble  reporting  packages 

i  •  Groupware 

;  •  Video  conferencing 

i  •  Integrated  decision  database 

:  •  Integrated  product  support  environments 


MA  Elaboration 

Staff  with  appropriate  expertise  provide  support  for  measurement  and 
analysis  activities.  A  measurement  group  with  such  a  role  may  exist. 

;  Examples  of  resources  provided  include  the  following: 

I  •  Statistical  packages 

i  •  Packages  that  support  data  collection  over  networks 


OPD  Elaboration 

A  process  group  typically  manages  organizational  process  definition 
activities.  This  group  typically  is  staffed  by  a  core  of  professionals  whose 
primary  responsibility  is  coordinating  organizational  process  improvement. 

f . . . . . . . 

I  This  group  is  supported  by  process  owners  and  people  with  expertise  in  various  disciplines 
i  such  as  the  following: 

i  •  Project  management 

;  •  The  appropriate  engineering  disciplines 

i  •  Configuration  management 

I  •  Quality  assurance 


Examples  of  resources  provided  include  the  following: 

•  Database  management  systems 

•  Process  modeling  tools 

•  Web  page  builders  and  browsers 
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OPF  Elaboration 

I  Examples  of  resources  provided  include  the  following: 

:  •  Database  management  systems 

I  •  Process  improvement  tools 

;  •  Web  page  builders  and  browsers 

i  •  Groupware 

;  •  Quality  improvement  tools  (e.g.,  cause-and-effect  diagrams,  affinity  diagrams,  Pareto 
I  charts) 


0PM  Elaboration 

I  Examples  of  resources  provided  include  the  following: 

:  •  Simulation  packages 

I  •  Prototyping  tools 

;  •  Statistical  packages 

i  •  Dynamic  systems  modeling 

;  •  Subscriptions  to  online  technology  databases  and  publications 

i  •  Process  modeling  tools 


OPP  Elaboration 

Special  expertise  in  statistical  and  other  quantitative  techniques  may  be 
needed  to  establish  process  performance  baselines  for  the  organization’s 
set  of  standard  processes. 

;  Examples  of  resources  provided  include  the  following: 

i  •  Database  management  systems 
;  •  System  dynamics  models 

i  •  Process  modeling  tools 

I  •  Statistical  analysis  packages 

I  •  Problem  tracking  packages 


OT  Elaboration 

f - - - - - - - - 

I  Examples  of  resources  provided  include  the  following: 

I  •  Subject  matter  experts 

;  •  Curriculum  designers 

i  •  Instructional  designers 

;  •  Instructors 

i*  Training  administrators 


Special  facilities  may  be  required  for  training.  When  necessary,  the  facilities 
required  for  the  activities  in  the  Organizational  Training  process  area  are 
developed  or  purchased. 
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Examples  of  resources  provided  include  the  following: 

•  Instruments  for  analyzing  training  needs 

•  Workstations  to  be  used  for  training 

•  Instructional  design  tools 

•  Packages  for  developing  presentation  materials 


PI  Elaboration 

Product  component  interface  coordination  can  be  accomplished  with  an 
Interface  Control  Working  Group  consisting  of  people  who  represent 
external  and  internal  interfaces.  Such  groups  can  be  used  to  elicit  needs  for 
interface  requirements  development. 

Special  facilities  may  be  required  for  assembling  and  delivering  the  product. 
When  necessary,  the  facilities  required  for  the  activities  in  the  Product 
Integration  process  area  are  developed  or  purchased. 

;  Examples  of  resources  provided  include  the  following: 

;  •  Prototyping  tools 

i  •  Analysis  tools 

;  •  Simulation  tools 

i  •  Interface  management  tools 

I  •  Assembly  tools  (e.g.,  compilers,  make  files,  joining  tools,  jigs,  fixtures) 


PMC  Elaboration 

I  Examples  of  resources  provided  include  the  following: 
:  •  Cost  tracking  systems 

I  •  Effort  reporting  systems 

I  •  Action  item  tracking  systems 

i  •  Project  management  and  scheduling  programs 


PP  Elaboration 

Special  expertise,  equipment,  and  facilities  in  project  planning  may  be 
required. 

i  Special  expertise  in  project  planning  can  include  the  following: 
i  •  Experienced  estimators 

I  •  Schedulers 

I  •  Technical  experts  in  applicable  areas  (e.g.,  product  domain,  technology) 
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Examples  of  resources  provided  include  the  following: 

•  Spreadsheet  programs 

•  Estimating  models 

•  Project  planning  and  scheduling  packages 


PPQA  Elaboration 

;  Examples  of  resources  provided  include  the  following: 
;  •  Evaluation  tools 

i  •  Noncompliance  tracking  tools 


QPM  Elaboration 

Special  expertise  in  statistics  and  its  use  in  analyzing  process  performance 
may  be  needed  to  define  the  analytic  techniques  used  in  quantitative 
management.  Special  expertise  in  statistics  can  also  be  needed  for 
analyzing  and  interpreting  the  measures  resulting  from  statistical  analyses; 
however,  teams  need  sufficient  expertise  to  support  a  basic  understanding 
of  their  process  performance  as  they  perform  their  daily  work. 

;  Examples  of  resources  provided  Include  the  following: 

;  •  Statistical  analysis  packages 
i  •  Statistical  process  and  quality  control  packages 

;  •  Scripts  and  tools  that  assist  teams  In  analyzing  their  own  process  performance  with 
I  minimal  need  for  additional  expert  assistance 


RD  Elaboration 

Special  expertise  in  the  application  domain,  methods  for  eliciting 
stakeholder  needs,  and  methods  and  tools  for  specifying  and  analyzing 
customer,  product,  and  product  component  requirements  may  be  required. 

i  Examples  of  resources  provided  Include  the  following: 

i  •  Requirements  specification  tools 

:  •  Simulators  and  modeling  tools 

I  •  Prototyping  tools 

I  •  Scenario  definition  and  management  tools 

i  •  Requirements  tracking  tools 


REQM  Elaboration 

;  Examples  of  resources  provided  Include  the  following: 
;  •  Requirements  tracking  tools 

i  •  Traceability  tools 
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RSKM  Elaboration 

I  Examples  of  resources  provided  include  the  following: 
:  •  Risk  management  databases 

I  •  Risk  mitigation  tools 

;  •  Prototyping  tools 

i  •  Modeling  and  simulation  tools 


SAM  Elaboration 

;  Examples  of  resources  provided  include  the  following: 
i  •  Preferred  supplier  lists 

;  •  Requirements  tracking  tools 

i  •  Project  management  and  scheduling  programs 


TS  Elaboration 

Special  facilities  may  be  required  for  developing,  designing,  and 
implementing  solutions  to  requirements.  When  necessary,  the  facilities 
required  for  the  activities  in  the  Technical  Solution  process  area  are 
developed  or  purchased. 

:  Examples  of  resources  provided  include  the  following: 
i  •  Design  specification  tools 

I  •  Simulators  and  modeling  tools 

I  •  Prototyping  tools 

;  •  Scenario  definition  and  management  tools 

i  •  Requirements  tracking  tools 

;  •  Interactive  documentation  tools 


VAL  Elaboration 

Special  facilities  may  be  required  for  validating  the  product  or  product 
components.  When  necessary,  the  facilities  required  for  validation  are 
developed  or  purchased. 

;  Examples  of  resources  provided  include  the  following: 

;  •  Test  management  tools 

i  •  Test  case  generators 

;•  Test  coverage  analyzers 
i  •  Simulators 

I  •  Load,  stress,  and  performance  testing  tools 
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VER  Elaboration 

Special  facilities  may  be  required  for  verifying  selected  work  products. 

When  necessary,  the  facilities  required  for  the  activities  in  the  Verification 
process  area  are  developed  or  purchased. 

Certain  verification  methods  can  require  special  tools,  equipment,  facilities, 
and  training  (e.g.,  peer  reviews  can  require  meeting  rooms  and  trained 
moderators;  certain  verification  tests  can  require  special  test  equipment  and 
people  skilled  in  the  use  of  the  equipment). 

i  Examples  of  resources  provided  Include  the  following: 

i  •  Test  management  tools 

:  •  Test  case  generators 

•  Test  coverage  analyzers 
;  •  Simulators 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
process. 

The  purpose  of  this  generic  practice  is  to  ensure  that  there  is  accountability 
for  performing  the  process  and  achieving  the  specified  results  throughout 
the  life  of  the  process.  The  people  assigned  must  have  the  appropriate 
authority  to  perform  the  assigned  responsibilities. 

Responsibility  can  be  assigned  using  detailed  job  descriptions  or  in  living 
documents,  such  as  the  plan  for  performing  the  process.  Dynamic 
assignment  of  responsibility  is  another  legitimate  way  to  implement  this 
generic  practice,  as  long  as  the  assignment  and  acceptance  of 
responsibility  are  ensured  throughout  the  life  of  the  process. 

Subpractices 

1 .  Assign  overall  responsibility  and  authority  for  performing  the  process. 

2.  Assign  responsibility  and  authority  for  performing  the  specific  tasks  of 
the  process. 

3.  Confirm  that  the  people  assigned  to  the  responsibilities  and  authorities 
understand  and  accept  them. 

OPF  Elaboration 

Two  groups  are  typically  established  and  assigned  responsibility  for 
process  improvement:  (1)  a  management  steering  committee  for  process 
improvement  to  provide  senior  management  sponsorship,  and  (2)  a  process 
group  to  facilitate  and  manage  the  process  improvement  activities. 
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PPQA  Elaboration 

Responsibility  is  assigned  to  those  who  can  perform  process  and  product 
quality  assurance  evaluations  with  sufficient  independence  and  objectivity 
to  guard  against  subjectivity  or  bias. 

TS  Elaboration 

Appointing  a  lead  or  chief  architect  that  oversees  the  technical  solution  and 
has  authority  over  design  decisions  helps  to  maintain  consistency  in 
product  design  and  evolution. 

GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  process  as  needed. 

The  purpose  of  this  generic  practice  is  to  ensure  that  people  have  the 
necessary  skills  and  expertise  to  perform  or  support  the  process. 

Appropriate  training  is  provided  to  those  who  will  be  performing  the  work. 
Overview  training  is  provided  to  orient  people  who  interact  with  those  who 
perform  the  work. 

;  Examples  of  methods  for  providing  training  Include  self  study;  self-directed  training;  self- 
i  paced,  programmed  Instruction;  formalized  on-the-job  training;  mentoring;  and  formal  and 
I  classroom  training. 


Training  supports  the  successful  execution  of  the  process  by  establishing  a 
common  understanding  of  the  process  and  by  imparting  the  skills  and 
knowledge  needed  to  perform  the  process. 

Refer  to  the  Organizational  Training  process  area  for  more  information 
about  developing  skills  and  knowledge  of  people  so  they  can  perform  their 
roles  effectively  and  efficiently. 

CAR  Elaboration 

;  Examples  of  training  topics  include  the  following: 

;  •  Quality  management  methods  (e.g.,  root  cause  analysis) 


CM  Elaboration 

;  Examples  of  training  topics  include  the  following: 

;  •  Roles,  responsibilities,  and  authority  of  the  configuration  management  staff 
i  •  Configuration  management  standards,  procedures,  and  methods 
;  •  Configuration  library  system 


DAR  Elaboration 

i  Examples  of  training  topics  include  the  following: 

;  •  Formal  decision  analysis 

;  •  Methods  for  evaluating  alternative  solutions  against  criteria 
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IPM  Elaboration 

I  Examples  of  training  topics  include  the  following: 

:  •  Tailoring  the  organization’s  set  of  standard  processes  to  meet  the  needs  of  the  project 
I  •  Managing  the  project  based  on  the  project’s  defined  process 
;  •  Using  the  organization’s  measurement  repository 
i  •  Using  the  organizational  process  assets 

;  •  Integrated  management 

i  •  Intergroup  coordination 

I  •  Group  problem  solving 


MA  Elaboration 

I  Examples  of  training  topics  include  the  following: 

:  •  Statistical  techniques 

I  •  Data  collection,  analysis,  and  reporting  processes 
;  •  Development  of  goal  related  measurements  (e.g..  Goal  Question  Metric) 


OPD  Elaboration 

;  Examples  of  training  topics  include  the  following: 

I  •  CMMI  and  other  process  and  process  improvement  reference  models 
i  •  Planning,  managing,  and  monitoring  processes 
i  •  Process  modeling  and  definition 

i  •  Developing  a  tailorable  standard  process 

:  •  Developing  work  environment  standards 

I  •  Ergonomics 


OPF  Elaboration 

f - ........... - - - 

I  Examples  of  training  topics  include  the  following: 

I  •  CMMI  and  other  process  improvement  reference  models 
I  •  Planning  and  managing  process  improvement 
;  •  Tools,  methods,  and  analysis  techniques 

i  •  Process  modeling 

i  •  Facilitation  techniques 

i  •  Change  management 
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OPM  Elaboration 

I  Examples  of  training  topics  include  the  following: 

:  •  Cost  benefit  analysis 

I  •  Planning,  designing,  and  conducting  pilots 

;  •  Technology  transition 

i  •  Change  management 

OPP  Elaboration 

f . . . . . . ----------------------- . . 

I  Examples  of  training  topics  include  the  following: 

I  •  Process  and  process  improvement  modeling 

I  •  Statistical  and  other  quantitative  methods  (e.g.,  estimating  models,  Pareto  analysis, 

;  control  charts) 


OT  Elaboration 

i  Examples  of  training  topics  include  the  following: 

;  •  Knowledge  and  skills  needs  analysis 

i  •  Instructional  design 

:  •  Instructional  techniques  (e.g.,  train  the  trainer) 
I  •  Refresher  training  on  subject  matter 


PI  Elaboration 

f . . 

I  Examples  of  training  topics  include  the  following: 

I  •  Application  domain 

;  •  Product  integration  procedures  and  criteria 

i  •  Organization’s  facilities  for  integration  and  assembly 
i  •  Assembly  methods 

i  •  Packaging  standards 


PMC  Elaboration 

i  Examples  of  training  topics  include  the  following: 
i  •  Monitoring  and  control  of  projects 

i  •  Risk  management 

I  •  Data  management 
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PP  Elaboration 

I  Examples  of  training  topics  include  the  following: 
:  •  Estimating 

I  •  Budgeting 

;  •  Negotiating 

i  •  Identifying  and  analyzing  risks 

;  •  Managing  data 

i  •  Planning 

I  •  Scheduling 


PPQA  Elaboration 

I  Examples  of  training  topics  include  the  following: 

:  •  Application  domain 
I  •  Customer  relations 

I  •  Process  descriptions,  standards,  procedures,  and  methods  for  the  project 

i  •  Quality  assurance  objectives,  process  descriptions,  standards,  procedures,  methods, 
i  and  tools 


QPM  Elaboration 

i  Examples  of  training  topics  include  the  following: 

i  •  Basic  quantitative  (including  statistical)  analyses  that  help  in  analyzing  process 
I  performance,  using  historical  data,  and  identifying  when  corrective  action  is  warranted 
;  •  Process  modeling  and  analysis 

i  •  Process  measurement  data  selection,  definition,  and  collection 


RD  Elaboration 

:  Examples  of  training  topics  include  the  following: 

i  •  Application  domain 
;  •  Requirements  definition  and  analysis 

i  •  Requirements  elicitation 

I  •  Requirements  specification  and  modeling 

I  •  Requirements  tracking 
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REQM  Elaboration 

I  Examples  of  training  topics  include  the  following: 

I  •  Application  domain 

I  •  Requirements  definition,  analysis,  review,  and  management 

;  •  Requirements  management  tools 

i  •  Configuration  management 

;  •  Negotiation  and  conflict  resolution 


RSKM  Elaboration 

;  Examples  of  training  topics  include  the  following: 

;  •  Risk  management  concepts  and  activities  (e.g.,  risk  identification,  evaluation, 
:  monitoring,  mitigation) 

I  •  Measure  selection  for  risk  mitigation 


SAM  Elaboration 

f - - - - 

I  Examples  of  training  topics  include  the  following: 

I  •  Regulations  and  business  practices  related  to  negotiating  and  working  with  suppliers 

;  •  Acquisition  planning  and  preparation 

i  •  Commercial  off-the-shelf  products  acquisition 

;  •  Supplier  evaluation  and  selection 

i  •  Negotiation  and  conflict  resolution 

:  •  Supplier  management 

I  •  Testing  and  transition  of  acquired  products 

;  •  Receiving,  storing,  using,  and  maintaining  acquired  products 


TS  Elaboration 

;  Examples  of  training  topics  include  the  following: 

;  •  Application  domain  of  the  product  and  product  components 
i  •  Design  methods 

i  •  Architecture  methods 

i  •  Interface  design 

:  •  Unit  testing  techniques 

I  •  Standards  (e.g.,  product,  safety,  human  factors,  environmental) 
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VAL  Elaboration 

I  Examples  of  training  topics  include  the  following: 

I  •  Application  domain 

I  •  Validation  principles,  standards,  and  methods 

;  •  Intended-use  environment 


VER  Elaboration 

;  Examples  of  training  topics  include  the  following: 

;  •  Application  or  service  domain 

i  •  Verification  principles,  standards,  and  methods  (e.g.,  analysis,  demonstration, 
i  inspection,  test) 

:  •  Verification  tools  and  facilities 

I  •  Peer  review  preparation  and  procedures 

;  •  Meeting  facilitation 


GP  2.6  Control  Work  Products 

Place  selected  work  products  of  the  process  under  appropriate 
levels  of  control. 

The  purpose  of  this  generic  practice  is  to  establish  and  maintain  the 
integrity  of  the  selected  work  products  of  the  process  (or  their  descriptions) 
throughout  their  useful  life. 

The  selected  work  products  are  specifically  identified  in  the  plan  for 
performing  the  process,  along  with  a  specification  of  the  appropriate  level  of 
control. 

Different  levels  of  control  are  appropriate  for  different  work  products  and  for 
different  points  in  time.  For  some  work  products,  it  may  be  sufficient  to 
maintain  version  control  so  that  the  version  of  the  work  product  in  use  at  a 
given  time,  past  or  present,  is  known  and  changes  are  incorporated  in  a 
controlled  manner.  Version  control  is  usually  under  the  sole  control  of  the 
work  product  owner  (which  can  be  an  individual,  group,  or  team). 

Sometimes,  it  can  be  critical  that  work  products  be  placed  under  formal  or 
baseline  configuration  management.  This  type  of  control  includes  defining 
and  establishing  baselines  at  predetermined  points.  These  baselines  are 
formally  reviewed  and  approved,  and  serve  as  the  basis  for  further 
development  of  the  designated  work  products. 

Refer  to  the  Configuration  Management  process  area  for  more  information 
about  estabiishing  and  maintaining  the  integrity  of  work  products  using 
configuration  identification,  configuration  controi,  configuration  status 
accounting,  and  configuration  audits. 

Additional  levels  of  control  between  version  control  and  formal  configuration 
management  are  possible.  An  identified  work  product  can  be  under  various 
levels  of  control  at  different  points  in  time. 
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CAR  Elaboration 

I  Examples  of  work  products  placed  under  control  include  the  following: 
:  •  Action  proposals 

I  •  Action  plans 

;  •  Causal  analysis  and  resolution  records 


CM  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 
;  •  Access  lists 

i  •  Change  status  reports 

;  •  Change  request  database 

i  •  CCB  meeting  minutes 

:  •  Archived  baselines 


DAR  Elaboration 

:  Examples  of  work  products  placed  under  control  include  the  following: 
:  •  Guidelinesfor  when  to  apply  a  formal  evaluation  process 
I  •  Evaluation  reports  containing  recommended  solutions 


I  PM  Elaboration 

f - - - - - - - - - 

I  Examples  of  work  products  placed  under  control  include  the  following: 

I  •  The  project’s  defined  process 

I  •  Project  plans 

;  •  Other  plans  that  affect  the  project 
i  •  Integrated  plans 

i  •  Actual  process  and  product  measurements  collected  from  the  project 
i  •  Project’s  shared  vision 
I  •  Team  structure 

;  •  Team  charters 


MA  Elaboration 

- - - - - - - - 

I  Examples  of  work  products  placed  under  control  include  the  following: 

I  •  Measurement  objectives 
;  •  Specifications  of  base  and  derived  measures 
i  •  Data  collection  and  storage  procedures 
;  •  Base  and  derived  measurement  data  sets 
i  •  Analysis  results  and  draft  reports 
I  •  Data  analysis  tools 
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OPD  Elaboration 

I  Examples  of  work  products  placed  under  control  include  the  following: 

:  •  Organization’s  set  of  standard  processes 
I  •  Descriptions  of  lifecycle  models 

;  •  Tailoring  guidelines  for  the  organization’s  set  of  standard  processes 
i  •  Definitions  of  the  common  set  of  product  and  process  measures 
;  •  Organization’s  measurement  data 
i  •  Rules  and  guidelines  for  structuring  and  forming  teams 


OPF  Elaboration 

i  Examples  of  work  products  placed  under  control  include  the  following: 

i  •  Process  improvement  proposals 

:  •  Organization’s  approved  process  action  plans 

I  •  Training  materials  used  for  deploying  organizational  process  assets 

;  •  Guidelines  for  deploying  the  organization’s  set  of  standard  processes  on  new  projects 

i  •  Plans  for  the  organization’s  process  appraisals 


0PM  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 
i  •  Documented  lessons  learned  from  improvement  validation 
i  •  Deployment  plans 

i  •  Revised  improvement  measures,  objectives,  priorities 
I  •  Updated  process  documentation  and  training  material 


OPP  Elaboration 

:  Examples  of  work  products  placed  under  control  include  the  following: 
i  •  Organization’s  quality  and  process  performance  objectives 
I  •  Definitions  of  the  selected  measures  of  process  performance 
I  •  Baseline  data  on  the  organization’s  process  performance 
;  •  Process  performance  models 


OT  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 
;  •  Organizational  training  tactical  plan 

i  •  Training  records 

;  •  Training  materials  and  supporting  artifacts 

:  •  Instructor  evaluation  forms 
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PI  Elaboration 

I  Examples  of  work  products  placed  under  control  include  the  following: 
:  •  Acceptance  documents  for  the  received  product  components 
I  •  Evaluated  assembled  product  and  product  components 
;  •  Product  integration  strategy 
i  •  Product  integration  procedures  and  criteria 
;  •  Updated  interface  description  or  agreement 


PMC  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 

;  •  Project  schedules  with  status 
i  •  Project  measurement  data  and  analysis 
:  •  Earned  value  reports 


PP  Elaboration 

:  Examples  of  work  products  placed  under  control  include  the  following: 
:  •  Work  breakdown  structure 

I  •  Project  plan 

I  •  Data  management  plan 

i  •  Stakeholder  involvement  plan 


PPQA  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 
;  •  Noncompliance  reports 

i  •  Evaluation  logs  and  reports 


QPM  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 
i  •  Subprocesses  to  be  included  in  the  project’s  defined  process 

;  •  Operational  definitions  of  the  measures,  their  collection  points  in  the  subprocesses,  and 
I  how  the  integrity  of  the  measures  will  be  determined 

;  •  Collected  measurements 
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RD  Elaboration 

I  Examples  of  work  products  placed  under  control  include  the  following: 
:  •  Customer  functional  and  quality  attribute  requirements 
I  •  Definition  of  required  functionality  and  quality  attributes 
;  •  Product  and  product  component  requirements 

i  •  Interface  requirements 


REQM  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 

i  •  Requirements 

;  •  Requirements  traceability  matrix 


RSKM  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 
i  •  Risk  management  strategy 

i  •  Identified  risk  items 

I  •  Risk  mitigation  plans 


SAM  Elaboration 

:  Examples  of  work  products  placed  under  control  include  the  following: 
i  •  Statements  of  work 

I  •  Supplier  agreements 

I  •  Memoranda  of  agreement 

;  •  Subcontracts 

i  •  Preferred  supplier  lists 


TS  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 

i  •  Product,  product  component,  and  interface  designs 

;  •  Technical  data  packages 

i  •  Interface  design  documents 

I  •  Criteria  for  design  and  product  component  reuse 

I  •  Implemented  designs  (e.g.,  software  code,  fabricated  product  components) 

;  •  User,  installation,  operation,  and  maintenance  documentation 
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VAL  Elaboration 

I  Examples  of  work  products  placed  under  control  include  the  following: 
:  •  Lists  of  products  and  product  components  selected  for  validation 
I  •  Validation  methods,  procedures,  and  criteria 

;  •  Validation  reports 


VER  Elaboration 

;  Examples  of  work  products  placed  under  control  include  the  following: 
I  •  Verification  procedures  and  criteria 

i  •  Peer  review  training  material 

;  •  Peer  review  data 

i  •  Verification  reports 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  process  as 
planned. 

The  purpose  of  this  generic  practice  is  to  establish  and  maintain  the 
expected  involvement  of  relevant  stakeholders  during  the  execution  of  the 
process. 

Involve  relevant  stakeholders  as  described  in  an  appropriate  plan  for 
stakeholder  involvement.  Involve  stakeholders  appropriately  in  activities 
such  as  the  following: 

•  Planning 

•  Decisions 

•  Commitments 

•  Communications 

•  Coordination 

•  Reviews 

•  Appraisals 

•  Requirements  definitions 

•  Resolution  of  problems  and  issues 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  stakeholder  involvement. 

The  objective  of  planning  stakeholder  involvement  is  to  ensure  that 
interactions  necessary  to  the  process  are  accomplished,  while  not  allowing 
excessive  numbers  of  affected  groups  and  individuals  to  impede  process 
execution. 
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Examples  of  stakeholders  that  might  serve  as  relevant  stakeholders  for  specific  tasks, 
depending  on  context,  Include  Individuals,  teams,  management,  customers,  suppliers,  end 
users,  operations  and  support  staff,  other  projects,  and  government  regulators. 


Subpractices 

1 .  Identify  stakeholders  relevant  to  this  process  and  their  appropriate 
involvement. 

Relevant  stakeholders  are  Identified  among  the  suppliers  of  Inputs  to,  the  users  of 
outputs  from,  and  the  performers  of  the  activities  In  the  process.  Once  the  relevant 
stakeholders  are  Identified,  the  appropriate  level  of  their  Involvement  In  process 
activities  Is  planned. 

2.  Share  these  identifications  with  project  planners  or  other  planners  as 
appropriate. 

3.  Involve  relevant  stakeholders  as  planned. 

CAR  Elaboration 

:  Examples  of  activities  for  stakeholder  Involvement  Include  the  following: 
i  •  Conducting  causal  analysis 

I  •  Assessing  action  proposals 


CM  Elaboration 

I  Examples  of  activities  for  stakeholder  Involvement  Include  the  following: 

:  •  Establishing  baselines 

I  •  Reviewing  configuration  management  system  reports  and  resolving  issues 
;  •  Assessing  the  impact  of  changes  for  configuration  items 
i  •  Performing  configuration  audits 
;  •  Reviewing  results  of  configuration  management  audits 


DAR  Elaboration 

;  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

;  •  Establishing  guidelines  for  which  issues  are  subject  to  a  formal  evaluation  process 
i  •  Defining  the  issue  to  be  addressed 
:  •  Establishing  evaluation  criteria 

I  •  Identifying  and  evaluating  alternatives 

I  •  Selecting  evaluation  methods 

i  •  Selecting  solutions 
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IPM  Elaboration 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

:  •  Resolving  issues  about  the  tailoring  of  organizational  process  assets 

I  •  Resolving  issues  among  the  project  plan  and  other  plans  that  affect  the  project 

;  •  Reviewing  project  progress  and  performance  to  align  with  current  and  projected  needs, 
;  objectives,  and  requirements 

I  •  Creating  the  project’s  shared  vision 
I  •  Defining  the  team  structure  for  the  project 
I  •  Populating  teams 


MA  Elaboration 

f - - - - - - - - - - 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

I  •  Establishing  measurement  objectives  and  procedures 
;  •  Assessing  measurement  data 

i  •  Providing  meaningful  feedback  to  those  who  are  responsible  for  providing  the  raw  data 
i  on  which  the  analysis  and  results  depend 


OPD  Elaboration 

:  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

i  •  Reviewing  the  organization’s  set  of  standard  processes 

I  •  Reviewing  the  organization’s  lifecycle  models 

I  •  Resolving  issues  related  to  the  tailoring  guidelines 

;  •  Assessing  definitions  of  the  common  set  of  process  and  product  measures 

i  •  Reviewing  work  environment  standards 

;  •  Establishing  and  maintaining  empowerment  mechanisms 

i  •  Establishing  and  maintaining  organizational  rules  and  guidelines  for  structuring  and 

;  forming  teams 
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OPF  Elaboration 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

I  •  Coordinating  and  collaborating  on  process  improvement  activities  with  process  owners, 
;  those  who  are  or  will  be  performing  the  process,  and  support  organizations  (e.g., 
i  training  staff,  quality  assurance  representatives) 

:  •  Establishing  the  organizational  process  needs  and  objectives 
I  •  Appraising  the  organization’s  processes 
I  •  Implementing  process  action  plans 

i  •  Coordinating  and  collaborating  on  the  execution  of  pilots  to  test  selected  improvements 
i  •  Deploying  organizational  process  assets  and  changes  to  organizational  process  assets 
i  •  Communicating  the  plans,  status,  activities,  and  results  related  to  planning, 

I  implementing,  and  deploying  process  improvements 


0PM  Elaboration 

f . . . - . - . - . 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

I  •  Reviewing  improvement  proposals  that  could  contribute  to  meeting  business  objectives 
I  •  Providing  feedback  to  the  organization  on  the  readiness,  status,  and  results  of  the 
;  improvement  deployment  activities 


The  feedback  typically  involves  the  following: 

•  Informing  the  people  who  submit  improvement  proposals  about  the  disposition  of  their 
proposals 

•  Regularly  communicating  the  results  of  comparing  business  performance  against  the 
business  objectives 

•  Regularly  informing  relevant  stakeholders  about  the  plans  and  status  for  selecting  and 
deploying  improvements 

•  Preparing  and  distributing  a  summary  of  improvement  selection  and  deployment 
activities 


OPP  Elaboration 

i  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

;  •  Establishing  the  organization’s  quality  and  process  performance  objectives  and  their 
I  priorities 

;  •  Reviewing  and  resolving  issues  on  the  organization’s  process  performance  baselines 

i  •  Reviewing  and  resolving  issues  on  the  organization’s  process  performance  models 
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OT  Elaboration 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

I  •  Establishing  a  collaborative  environment  for  discussion  of  training  needs  and  training 
;  effectiveness  to  ensure  that  the  organization’s  training  needs  are  met 
i  •  Identifying  training  needs 
;  •  Reviewing  the  organizational  training  tactical  plan 
I  •  Assessing  training  effectiveness 


PI  Elaboration 

:  Examples  of  activities  for  stakeholder  involvement  include  the  following: 
i  •  Establishing  the  product  integration  strategy 
:  •  Reviewing  interface  descriptions  for  completeness 
I  •  Establishing  the  product  integration  procedures  and  criteria 
;  •  Assembling  and  delivering  the  product  and  product  components 
i  •  Communicating  the  results  after  evaluation 

;  •  Communicating  new,  effective  product  integration  processes  to  give  affected  people  the 
j  opportunity  to  improve  their  process  performance 


PMC  Elaboration 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

I  •  Assessing  the  project  against  the  plan 

I  •  Reviewing  commitments  and  resolving  issues 

;  •  Reviewing  project  risks 

i  •  Reviewing  data  management  activities 

;  •  Reviewing  project  progress 

I  •  Managing  corrective  actions  to  closure 


PP  Elaboration 

:  Examples  of  activities  for  stakeholder  involvement  include  the  following: 
i  •  Establishing  estimates 

I  •  Reviewing  and  resolving  issues  on  the  completeness  and  correctness  of  the  project 
;  risks 

i  •  Reviewing  data  management  plans 

;  •  Establishing  project  plans 

i  •  Reviewing  project  plans  and  resolving  issues  on  work  and  resource  issues 
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PPQA  Elaboration 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

:  •  Establishing  criteria  for  the  objective  evaluations  of  processes  and  work  products 
I  •  Evaluating  processes  and  work  products 
;  •  Resolving  noncompliance  issues 
i  •  Tracking  noncompliance  issues  to  closure 


QPM  Elaboration 

;  Examples  of  activities  for  stakeholder  involvement  include  the  following: 
i*  Establishing  project  objectives 

;  •  Resolving  issues  among  the  project’s  quality  and  process  performance  objectives 

i  •  Selecting  analytic  techniques  to  be  used 

:  •  Evaluating  the  process  performance  of  selected  subprocesses 

I  •  Identifying  and  managing  the  risks  in  achieving  the  project’s  quality  and  process 

i  performance  objectives 

;  •  Identifying  what  corrective  action  should  be  taken 


RD  Elaboration 

i  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

;  •  Reviewing  the  adequacy  of  requirements  in  meeting  needs,  expectations,  constraints, 

I  and  interfaces 

I  •  Establishing  operational  concepts  and  operational,  sustainment,  and  development 
i  scenarios 

i  •  Assessing  the  adequacy  of  requirements 

:  •  Prioritizing  customer  requirements 

I  •  Establishing  product  and  product  component  functional  and  quality  attribute 
i  requirements 

;  •  Assessing  product  cost,  schedule,  and  risk 


REQM  Elaboration 

;  Examples  of  activities  for  stakeholder  involvement  include  the  following: 
i  •  Resolving  issues  on  the  understanding  of  requirements 
i  •  Assessing  the  impact  of  requirements  changes 
I  •  Communicating  bidirectional  traceability 

I  •  Identifying  inconsistencies  among  requirements,  project  plans,  and  work  products 
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RSKM  Elaboration 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

:  •  Establishing  a  collaborative  environment  for  free  and  open  discussion  of  risk 
I  •  Reviewing  the  risk  management  strategy  and  risk  mitigation  plans 
;  •  Participating  in  risk  identification,  analysis,  and  mitigation  activities 
i  •  Communicating  and  reporting  risk  management  status 


SAM  Elaboration 

;  Examples  of  activities  for  stakeholder  involvement  include  the  following: 
i  •  Establishing  criteria  forevaluation  of  potential  suppliers 

;  •  Reviewing  potential  suppliers 

i  •  Establishing  supplier  agreements 

:  •  Resolving  issues  with  suppliers 

;  •  Reviewing  supplier  performance 


TS  Elaboration 

f - - - - - - - - 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 

I  •  Developing  alternative  solutions  and  selection  criteria 
I  •  Obtaining  approval  on  external  interface  specifications  and  design  descriptions 
i  •  Developing  the  technical  data  package 

i  •  Assessing  the  make,  buy,  or  reuse  alternatives  for  product  components 
i  •  Implementing  the  design 


VAL  Elaboration 

i  Examples  of  activities  for  stakeholder  involvement  include  the  following: 
i  •  Selecting  the  products  and  product  components  to  be  validated 
i  •  Establishing  the  validation  methods,  procedures,  and  criteria 
I  •  Reviewing  results  of  product  and  product  component  validation  and  resolving  issues 
;  •  Resolving  issues  with  the  customers  or  end  users 


;  Issues  with  the  customers  or  end  users  are  resolved  particularly  when  there  are  significant 
;  deviations  from  their  baseline  needs.  Examples  of  resolutions  include  the  following: 

;  •  Waivers  on  the  contract  or  agreement  (what,  when,  and  for  which  products) 
i  •  Additional  in-depth  studies,  trials,  tests,  or  evaluations 
:  •  Possible  changes  in  the  contracts  or  agreements 
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VER  Elaboration 

I  Examples  of  activities  for  stakeholder  involvement  include  the  following: 
:  •  Selecting  work  products  and  methods  for  verification 
I  •  Establishing  verification  procedures  and  criteria 
;  •  Conducting  peer  reviews 

i  •  Assessing  verification  results  and  identifying  corrective  action 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  process  against  the  plan  for  performing 
the  process  and  take  appropriate  corrective  action. 

The  purpose  of  this  generic  practice  is  to  perform  the  direct  day-to-day 
monitoring  and  controlling  of  the  process.  Appropriate  visibility  into  the 
process  is  maintained  so  that  appropriate  corrective  action  can  be  taken 
when  necessary.  Monitoring  and  controlling  the  process  can  involve 
measuring  appropriate  attributes  of  the  process  or  work  products  produced 
by  the  process. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  developing  and  sustaining  a  measurement  capability  used  to  support 
management  information  needs. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  providing  an  understanding  of  the  project’s  progress  so 
that  appropriate  corrective  actions  can  be  taken  when  the  project’s 
performance  deviates  significantly  from  the  plan. 

Subpractices 

1 .  Evaluate  actual  progress  and  performance  against  the  plan  for 
performing  the  process. 

The  evaluations  are  of  the  process,  its  work  products,  and  its  services. 

2.  Review  accomplishments  and  results  of  the  process  against  the  plan 
for  performing  the  process. 

3.  Review  activities,  status,  and  results  of  the  process  with  the  immediate 
level  of  management  responsible  for  the  process  and  identify  issues. 

These  reviews  are  intended  to  provide  the  immediate  level  of  management  with 
appropriate  visibility  into  the  process  based  on  the  day-to-day  monitoring  and 
controlling  of  the  process,  and  are  supplemented  by  periodic  and  event-driven  reviews 
with  higher  level  management  as  described  in  GP  2.10. 

4.  Identify  and  evaluate  the  effects  of  significant  deviations  from  the  plan 
for  performing  the  process. 

5.  Identify  problems  in  the  plan  for  performing  the  process  and  in  the 
execution  of  the  process. 
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6.  Take  corrective  action  when  requirements  and  objectives  are  not  being 
satisfied,  when  issues  are  identified,  or  when  progress  differs 
significantly  from  the  plan  for  performing  the  process. 

Inherent  risks  should  be  considered  before  any  corrective  action  is  taken. 

i  Corrective  action  can  include  the  following: 

;  •  Taking  remedial  action  to  repair  defective  work  products  or  services 
;  •  Changing  the  plan  for  performing  the  process 
i  •  Adjusting  resources,  including  people,  tools,  and  other  resources 
i  •  Negotiating  changes  to  the  established  commitments 
I  •  Securing  change  to  the  requirements  and  objectives  that  must  be  satisfied 
I  •  Terminating  the  effort 

7.  Track  corrective  action  to  closure. 

CAR  Elaboration 

:  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

i  •  Number  of  outcomes  analyzed 

i  •  Change  in  quality  or  process  performance  per  instance  of  the  causal  analysis  and 
I  resolution  process 

i  •  Schedule  of  activities  for  implementing  a  selected  action  proposal 


CM  Elaboration 

:  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
I  following: 

i  •  Number  of  changes  to  configuration  items 
:  •  Number  of  configuration  audits  conducted 
:  •  Schedule  of  CCB  or  audit  activities 


DAR  Elaboration 

I  -  -  - . . . . . 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

i  •  Cost-to-benefit  ratio  of  using  formal  evaluation  processes 
;  •  Schedule  for  the  execution  of  a  trade  study 
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IPM  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

;  •  Number  of  changes  to  the  project’s  defined  process 
i  •  Schedule  and  effort  to  tailor  the  organization’s  set  of  standard  processes 

;  •  Interface  coordination  issue  trends  (i.e.,  number  identified  and  number  closed) 

I  •  Schedule  for  project  tailoring  activities 
I  •  Project's  shared  vision  usage  and  effectiveness 
I  •  Team  structure  usage  and  effectiveness 
;  •  Team  charters  usage  and  effectiveness 


MA  Elaboration 

;  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

i  •  Percentage  of  projects  using  progress  and  performance  measures 
i  •  Percentage  of  measurement  objectives  addressed 
i  •  Schedule  for  collection  and  review  of  measurement  data 


OPD  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

i  •  Percentage  of  projects  using  the  process  architectures  and  process  elements  of  the 
i  organization’s  set  of  standard  processes 

:  •  Defect  density  of  each  process  element  of  the  organization’s  set  of  standard  processes 
I  •  Schedule  for  development  of  a  process  or  process  change 


OPF  Elaboration 

f . . . . . - . 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

i  •  Number  of  process  improvement  proposals  submitted,  accepted,  or  implemented 
;  •  CMMI  maturity  level  or  capability  level  earned 
i  •  Schedule  for  deployment  of  an  organizational  process  asset 
I  •  Percentage  of  projects  using  the  current  organization’s  set  of  standard  processes  (or 
;  tailored  version  of  the  current  set) 

i  •  Issue  trends  associated  with  implementing  the  organization’s  set  of  standard  processes 
:  (i.e.,  number  of  issues  identified,  number  closed) 

I  •  Progress  toward  achievement  of  process  needs  and  objectives 
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OPM  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

;  •  Change  in  quality  and  process  performance  related  to  business  objectives 
i  •  Schedule  for  implementing  and  validating  an  improvement 
;  •  Schedule  for  activities  to  deploy  a  selected  improvement 


OPP  Elaboration 

i  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
I  following: 

j  •  Trends  in  the  organization’s  process  performance  with  respect  to  changes  in  work 
i  products  and  task  attributes  (e.g.,  size  growth,  effort,  schedule,  quality) 
i  •  Schedule  for  collecting  and  reviewing  measures  to  be  used  for  establishing  a  process 
I  performance  baseline 


OT  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
;  following: 

;  •  Number  of  training  courses  delivered  (e.g.,  planned  versus  actual) 
i  •  Post-training  evaluation  ratings 
;  •  Training  program  quality  survey  ratings 
i  •  Schedule  for  delivery  of  training 
I  •  Schedule  for  development  of  a  course 


PI  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

;  •  Product  component  integration  profile  (e.g.,  product  component  assemblies  planned 
i  and  performed,  number  of  exceptions  found) 

:  •  Integration  evaluation  problem  report  trends  (e.g.,  number  written  and  number  closed) 

I  •  Integration  evaluation  problem  report  aging  (i.e.,  how  long  each  problem  report  has 

i  been  open) 

;  •  Schedule  for  conduct  of  specific  integration  activities 


Generic  Goals  and  Generic  Practices 


103 


CMMI  for  Development,  Version  1.3 


PMC  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

;  •  Number  of  open  and  closed  corrective  actions 

i  •  Schedule  with  status  for  monthly  financial  data  collection,  analysis,  and  reporting 
;  •  Number  and  types  of  reviews  performed 
I  •  Review  schedule  (planned  versus  actual  and  slipped  target  dates) 

I  •  Schedule  for  collection  and  analysis  of  monitoring  data 


PP  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

;  •  Number  of  revisions  to  the  plan 

i  •  Cost,  schedule,  and  effort  variance  per  plan  revision 

i  •  Schedule  for  development  and  maintenance  of  program  plans 


PPQA  Elaboration 

i  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
I  following: 

I  •  Variance  of  objective  process  evaluations  planned  and  performed 
;  •  Variance  of  objective  work  product  evaluations  planned  and  performed 
i  •  Schedule  for  objective  evaluations 


QPM  Elaboration 

;  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

i  •  Profile  of  subprocess  attributes  whose  process  performance  provide  insight  about  the 
I  risk  to,  or  are  key  contributors  to,  achieving  project  objectives  (e.g.,  number  selected  for 
i  monitoring  through  statistical  techniques,  number  currently  being  monitored,  number 
:  whose  process  performance  is  stable) 

I  •  Number  of  special  causes  of  variation  identified 

I  •  Schedule  of  data  collection,  analysis,  and  reporting  activities  in  a  measurement  and 
;  analysis  cycle  as  it  relates  to  quantitative  management  activities 


RD  Elaboration 

;  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
I  following: 

I  •  Cost,  schedule,  and  effort  expended  for  rework 
I  •  Defectdensity  of  requirements  specifications 
;  •  Schedule  for  activities  to  develop  a  set  of  requirements 
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REQM  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

;  •  Requirements  volatility  (percentage  of  requirements  changed) 
i  •  Schedule  for  coordination  of  requirements 
;  •  Schedule  for  analysis  of  a  proposed  requirements  change 


RSKM  Elaboration 

i  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
I  following: 

I  •  Number  of  risks  identified,  managed,  tracked,  and  controlled 
I  •  Risk  exposure  and  changes  to  the  risk  exposure  for  each  assessed  risk,  and  as  a 
i  summary  percentage  of  management  reserve 

i  •  Change  activity  for  risk  mitigation  plans  (e.g.,  processes,  schedule,  funding) 

:  •  Occurrence  of  unanticipated  risks 

I  •  Risk  categorization  volatility 

I  •  Comparison  of  estimated  versus  actual  risk  mitigation  effort  and  impact 
i  •  Schedule  for  risk  analysis  activities 
i  •  Schedule  of  actions  for  a  specific  mitigation 


SAM  Elaboration 

;  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
:  following: 

:  •  Number  of  changes  made  to  the  requirements  for  the  supplier 
I  •  Cost  and  schedule  variance  in  accordance  with  the  supplier  agreement 
I  •  Schedule  for  selecting  a  supplier  and  establishing  an  agreement 


TS  Elaboration 

;  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
;  following: 

;  •  Cost,  schedule,  and  effort  expended  for  rework 

i  •  Percentage  of  requirements  addressed  in  the  product  or  product  component  design 
:  •  Size  and  complexity  of  the  product,  product  components,  interfaces,  and  documentation 
I  •  Defect  density  of  technical  solutions  work  products 
;  •  Schedule  for  design  activities 
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VAL  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
i  following: 

;  •  Number  of  validation  activities  completed  (planned  versus  actual) 
i  •  Validation  problem  report  trends  (e.g.,  number  written,  number  closed) 

;  •  Validation  problem  report  aging  (i.e.,  how  long  each  problem  report  has  been  open) 

I  •  Schedule  for  a  specific  validation  activity 


VER  Elaboration 

I  Examples  of  measures  and  work  products  used  in  monitoring  and  controlling  include  the 
;  following: 

;  •  Verification  profile  (e.g.,  the  number  of  verifications  planned  and  performed,  and  the 
i  defects  found;  or  defects  categorized  by  verification  method  or  type) 

i  •  Number  of  defects  detected  by  defect  category 
:  •  Verification  problem  report  trends  (e.g.,  number  written,  number  closed) 

I  •  Verification  problem  report  status  (i.e.,  how  long  each  problem  report  has  been  open) 

I  •  Schedule  for  a  specific  verification  activity 
i  •  Peer  review  effectiveness 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  process  and  selected  work 
products  against  the  process  description,  standards,  and 
procedures,  and  address  noncompliance. 

The  purpose  of  this  generic  practice  is  to  provide  credible  assurance  that 
the  process  and  selected  work  products  are  implemented  as  planned  and 
adhere  to  the  process  description,  standards,  and  procedures.  (See  the 
definition  of  “objectively  evaluate”  in  the  glossary.) 

Refer  to  the  Process  and  Product  Quality  Assurance  process  area  for  more 
information  about  objectively  evaluating  processes  and  work  products. 

People  not  directly  responsible  for  managing  or  performing  the  activities  of 
the  process  typically  evaluate  adherence.  In  many  cases,  adherence  is 
evaluated  by  people  in  the  organization,  but  external  to  the  process  or 
project,  or  by  people  external  to  the  organization.  As  a  result,  credible 
assurance  of  adherence  can  be  provided  even  during  times  when  the 
process  is  under  stress  (e.g.,  when  the  effort  is  behind  schedule,  when  the 
effort  is  over  budget). 

CAR  Elaboration 

i  Examples  of  activities  reviewed  include  the  following: 

:•  Determining  causes  of  outcomes 
I  •  Evaluating  results  of  action  plans 
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Examples  of  work  products  reviewed  include  the  following: 

•  Action  proposals  selected  for  implementation 

•  Causal  analysis  and  resolution  records 


CM  Elaboration 

f - - - - - 

I  Examples  of  activities  reviewed  include  the  following: 

I  •  Establishing  baselines 

;•  Tracking  and  controlling  changes 

i  •  Establishing  and  maintaining  the  integrity  of  baselines 


Examples  of  work  products  reviewed  include  the  following: 

•  Archives  of  baselines 

•  Change  request  database 


DAR  Elaboration 

i  Examples  of  activities  reviewed  include  the  following: 

;  •  Evaluating  alternatives  using  established  criteria  and  methods 

i  Examples  of  work  products  reviewed  include  the  following: 

;  •  Guidelinesfor  when  to  apply  a  formal  evaluation  process 
:  •  Evaluation  reports  containing  recommended  solutions 


I  PM  Elaboration 

i  Examples  of  activities  reviewed  include  the  following: 

i  •  Establishing,  maintaining,  and  using  the  project’s  defined  process 
:  •  Coordinating  and  collaborating  with  relevant  stakeholders 
I  •  Using  the  project's  shared  vision 

;  •  Organizing  teams 


Examples  of  work  products  reviewed  include  the  following: 

•  Project’s  defined  process 

•  Project  plans 

•  Other  plans  that  affect  the  project 

•  Work  environment  standards 

•  Shared  vision  statements 

•  Team  structure 

•  Team  charters 
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MA  Elaboration 

I  Examples  of  activities  reviewed  include  the  following: 
:  •  Aligning  measurement  and  analysis  activities 
I  •  Providing  measurement  results 


f - - - - - 

I  Examples  of  work  products  reviewed  include  the  following: 

I  •  Specifications  of  base  and  derived  measures 
;  •  Data  collection  and  storage  procedures 
i  •  Analysis  results  and  draft  reports 


OPD  Elaboration 

:  Examples  of  activities  reviewed  include  the  following: 

i  •  Establishing  organizational  process  assets 
;  •  Determining  rules  and  guidelines  for  structuring  and  forming  teams 


Examples  of  work  products  reviewed  include  the  following: 

•  Organization’s  set  of  standard  processes 

•  Descriptions  of  lifecycle  models 

•  Tailoring  guidelines  for  the  organization’s  set  of  standard  processes 

•  Organization’s  measurement  data 

•  Empowerment  rules  and  guidelines  for  people  and  teams 

•  Organizational  process  documentation 


OPF  Elaboration 

:  Examples  of  activities  reviewed  include  the  following: 
i  •  Determining  process  improvement  opportunities 
;  •  Planning  and  coordinating  process  improvement  activities 
i  •  Deploying  the  organization’s  set  of  standard  processes  on  projects  at  their  startup 


Examples  of  work  products  reviewed  include  the  following: 

•  Process  improvement  plans 

•  Process  action  plans 

•  Process  deployment  plans 

•  Plans  for  the  organization’s  process  appraisals 


108 


Generic  Goals  and  Generic  Practices 


CMMI  for  Development,  Version  1.3 


OPM  Elaboration 

I  Examples  of  activities  reviewed  include  the  following: 

I  •  Analyzing  process  performance  data  to  determine  the  organization’s  ability  to  meet 
;  identified  business  objectives 

i  •  Selecting  improvements  using  quantitative  analysis 

;  •  Deploying  improvements 

I  •  Measuring  effectiveness  of  the  deployed  improvements  using  statistical  and  other 

;  quantitative  techniques 


;  Examples  of  work  products  reviewed  include  the  following: 

;  •  Improvement  proposals 

i  •  Deployment  plans 

i  •  Revised  improvement  measures,  objectives,  priorities,  and  deployment  plans 
i  •  Updated  process  documentation  and  training  material 


OPP  Elaboration 

i  Examples  of  activities  reviewed  include  the  following: 
i  •  Establishing  process  performance  baselines  and  models 


Examples  of  work  products  reviewed  include  the  following: 

•  Process  performance  baselines 

•  Organization’s  quality  and  process  performance  objectives 

•  Definitions  of  the  selected  measures  of  process  performance 


OT  Elaboration 

f - 

I  Examples  of  activities  reviewed  include  the  following: 

I  •  Identifying  training  needs  and  making  training  available 
;  •  Providing  necessary  training 


;  Examples  of  work  products  reviewed  include  the  following: 

;  •  Organizational  training  tactical  plan 
i  •  Training  materials  and  supporting  artifacts 
i  •  Instructor  evaluation  forms 
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PI  Elaboration 

I  Examples  of  activities  reviewed  include  the  following: 

:  •  Establishing  and  maintaining  a  product  integration  strategy 
I  •  Ensuring  interface  compatibility 
;  •  Assembling  product  components  and  delivering  the  product 


;  Examples  of  work  products  reviewed  include  the  following: 

;  •  Product  integration  strategy 
i  •  Product  integration  procedures  and  criteria 
;  •  Acceptance  documents  for  the  received  product  components 
i  •  Assembled  product  and  product  components 


PMC  Elaboration 

i  Examples  of  activities  reviewed  include  the  following: 
i  •  Monitoring  project  progress  and  performance  against  the  project  plan 
I  •  Managing  corrective  actions  to  closure 


Examples  of  work  products  reviewed  include  the  following: 

•  Records  of  project  progress  and  performance 

•  Project  review  results 


PP  Elaboration 

f - - 

I  Examples  of  activities  reviewed  include  the  following: 

I  •  Establishing  estimates 

;  •  Developing  the  project  plan 

i  •  Obtaining  commitments  to  the  project  plan 


Examples  of  work  products  reviewed  include  the  following: 

•  WBS 

•  Project  plan 

•  Data  management  plan 

•  Stakeholder  involvement  plan 


PPQA  Elaboration 

I  Examples  of  activities  reviewed  include  the  following: 

:  •  Objectively  evaluating  processes  and  work  products 
;  •  Tracking  and  communicating  noncompliance  issues 
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Examples  of  work  products  reviewed  include  the  following: 

•  Noncompliance  reports 

•  Evaluation  logs  and  reports 


QPM  Elaboration 

f - - - - - - - - - - 

I  Examples  of  activities  reviewed  include  the  following: 

I  •  Managing  the  project  using  quality  and  process  performance  objectives 
;  •  Managing  selected  subprocesses  using  statistical  and  other  quantitative  techniques 


Examples  of  work  products  reviewed  include  the  following: 

•  Compositions  of  the  project’s  defined  process 

•  Operational  definitions  of  the  measures 

•  Process  performance  analyses  reports 

•  Collected  measurements 


RD  Elaboration 

:  Examples  of  activities  reviewed  include  the  following: 
i  •  Collecting  stakeholder  needs 

I  •  Formulating  product  and  product  component  functional  and  quality  attribute 
;  requirements 

i  •  Formulating  architectural  requirements  that  specify  how  product  components  are 
I  organized  and  designed  to  achieve  particular  end-to-end  functional  and  quality  attribute 

;  requirements 

i  •  Analyzing  and  validating  product  and  product  component  requirements 


Examples  of  work  products  reviewed  include  the  following: 

•  Product  requirements 

•  Product  component  requirements 

•  Interface  requirements 

•  Definition  of  required  functionality  and  quality  attributes 

•  Architecturally  significant  quality  attribute  requirements 


REQM  Elaboration 

f - - 

I  Examples  of  activities  reviewed  include  the  following: 

I  •  Managing  requirements 

;  •  Ensuring  alignment  among  project  plans,  work  products,  and  requirements 
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Examples  of  work  products  reviewed  include  the  following: 

•  Requirements 

•  Requirements  traceability  matrix 


RSKM  Elaboration 

f - - - - - - - - - 

I  Examples  of  activities  reviewed  include  the  following: 

I  •  Establishing  and  maintaining  a  risk  management  strategy 
;  •  Identifying  and  analyzing  risks 

i  •  Mitigating  risks 


Examples  of  work  products  reviewed  include  the  following: 

•  Risk  management  strategy 

•  Risk  mitigation  plans 


SAM  Elaboration 

i  Examples  of  activities  reviewed  include  the  following: 

;  •  Establishing  and  maintaining  supplier  agreements 
i  •  Satisfying  supplier  agreements 


Examples  of  work  products  reviewed  include  the  following: 

•  Plan  for  supplier  agreement  management 

•  Supplier  agreements 


TS  Elaboration 

I  Examples  of  activities  reviewed  include  the  following: 

:  •  Selecting  product  component  solutions 
I  •  Developing  product  and  product  component  designs 
;  •  Implementing  product  component  designs 


;  Examples  of  work  products  reviewed  include  the  following: 

;  •  Technical  data  packages 
i  •  Product,  product  component,  and  interface  designs 
;  •  Implemented  designs  (e.g.,  software  code,  fabricated  product  components) 
i  •  User,  installation,  operation,  and  maintenance  documentation 
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VAL  Elaboration 

I  Examples  of  activities  reviewed  include  the  following: 

:  •  Selecting  the  products  and  product  components  to  be  validated 
I  •  Establishing  and  maintaining  validation  methods,  procedures,  and  criteria 
;  •  Validating  products  or  product  components 


Examples  of  work  products  reviewed  include  the  following: 

•  Validation  methods 

•  Validation  procedures 

•  Validation  criteria 


VER  Elaboration 

i  Examples  of  activities  reviewed  include  the  following: 

;  •  Selecting  work  products  for  verification 
i  •  Establishing  and  maintaining  verification  procedures  and  criteria 
:  •  Performing  peer  reviews 

I  •  Verifying  selected  work  products 


f - - - - - - - - - 

I  Examples  of  work  products  reviewed  include  the  following: 

I  •  Verification  procedures  and  criteria 

;  •  Peer  review  checklists 

i  •  Verification  reports 


GP  2.10  Review  Status  with  Higher  Levei  Management 

Review  the  activities,  status,  and  resuits  of  the  process  with  higher 
/eve/  management  and  resoive  issues. 

The  purpose  of  this  generic  practice  is  to  provide  higher  level  management 
with  the  appropriate  visibility  into  the  process. 

Higher  level  management  includes  those  levels  of  management  in  the 
organization  above  the  immediate  level  of  management  responsible  for  the 
process.  In  particular,  higher  level  management  can  include  senior 
management.  These  reviews  are  for  managers  who  provide  the  policy  and 
overall  guidance  for  the  process  and  not  for  those  who  perform  the  direct 
day-to-day  monitoring  and  controlling  of  the  process. 

Different  managers  have  different  needs  for  information  about  the  process. 
These  reviews  help  ensure  that  informed  decisions  on  the  planning  and 
performing  of  the  process  can  be  made.  Therefore,  these  reviews  are 
expected  to  be  both  periodic  and  event  driven. 
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OPF  Elaboration 

These  reviews  are  typically  in  the  form  of  a  briefing  presented  to  the 
management  steering  committee  by  the  process  group  and  the  process 
action  teams. 

i  Examples  of  presentation  topics  include  the  following: 

;  •  Status  of  improvements  being  developed  by  process  action  teams 
I  •  Results  of  pilots 

I  •  Results  of  deployments 

I  •  Schedule  status  for  achieving  significant  milestones  (e.g.,  readiness  for  an  appraisal, 
i  progress  toward  achieving  a  targeted  organizational  maturity  level  or  capability  level 
I  profile) 


0PM  Elaboration 

These  reviews  are  typically  in  the  form  of  a  briefing  presented  to  higher 
level  management  by  those  responsible  for  performance  improvement. 

;  Examples  of  presentation  topics  include  the  following: 

;  •  Improvement  areas  identified  from  analysis  of  current  performance  compared  to 
;  business  objectives 

i  •  Results  of  process  improvement  elicitation  and  analysis  activities 

I  •  Results  from  validation  activities  (e.g.,  pilots)  compared  to  expected  benefits 

I  •  Performance  data  after  deployment  of  improvements 
;  •  Deployment  cost,  schedule,  and  risk 
i  •  Risks  of  not  achieving  business  objectives 


REQM  Elaboration 

Proposed  changes  to  commitments  to  be  made  external  to  the  organization 
are  reviewed  with  higher  level  management  to  ensure  that  all  commitments 
can  be  accomplished. 

RSKM  Elaboration 

Reviews  of  the  project  risk  status  are  held  on  a  periodic  and  event  driven 
basis,  with  appropriate  levels  of  management,  to  provide  visibility  into  the 
potential  for  project  risk  exposure  and  appropriate  corrective  action. 

Typically,  these  reviews  include  a  summary  of  the  most  critical  risks,  key 
risk  parameters  (such  as  likelihood  and  consequence  of  the  risks),  and  the 
status  of  risk  mitigation  efforts. 
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GG  3  Institutionalize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  process. 

The  purpose  of  this  generic  practice  is  to  establish  and  maintain  a 
description  of  the  process  that  is  tailored  from  the  organization’s  set  of 
standard  processes  to  address  the  needs  of  a  specific  instantiation.  The 
organization  should  have  standard  processes  that  cover  the  process  area, 
as  well  as  have  guidelines  for  tailoring  these  standard  processes  to  meet 
the  needs  of  a  project  or  organizational  function.  With  a  defined  process, 
variability  in  how  the  processes  are  performed  across  the  organization  is 
reduced  and  process  assets,  data,  and  learning  can  be  effectively  shared. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  standard  processes  and  establishing  tailoring 
criteria  and  guidelines. 

The  descriptions  of  the  defined  processes  provide  the  basis  for  planning, 
performing,  and  managing  the  activities,  work  products,  and  services 
associated  with  the  process. 

Subpractices 

1 .  Select  from  the  organization’s  set  of  standard  processes  those 
processes  that  cover  the  process  area  and  best  meet  the  needs  of  the 
project  or  organizational  function. 

2.  Establish  the  defined  process  by  tailoring  the  selected  processes 
according  to  the  organization’s  tailoring  guidelines. 

3.  Ensure  that  the  organization’s  process  objectives  are  appropriately 
addressed  in  the  defined  process. 

4.  Document  the  defined  process  and  the  records  of  the  tailoring. 

5.  Revise  the  description  of  the  defined  process  as  necessary. 

GP  3.2  Collect  Process  Related  Experiences 

Collect  process  related  experiences  derived  from  planning  and 
performing  the  process  to  support  the  future  use  and  improvement 
of  the  organization’s  processes  and  process  assets. 

The  purpose  of  this  generic  practice  is  to  collect  process  related 
experiences,  including  information  and  artifacts  derived  from  planning  and 
performing  the  process.  Examples  of  process  related  experiences  include 
work  products,  measures,  measurement  results,  lessons  learned,  and 
process  improvement  suggestions.  The  information  and  artifacts  are 
collected  so  that  they  can  be  included  in  the  organizational  process  assets 
and  made  available  to  those  who  are  (or  who  will  be)  planning  and 


Generic  Goals  and  Generic  Practices 


115 


CMMI  for  Development,  Version  1.3 


performing  the  same  or  similar  processes.  The  information  and  artifacts  are 
stored  in  the  organization’s  measurement  repository  and  the  organization’s 
process  asset  library. 

Examples  of  relevant  Information  Include  the  effort  expended  for  the  various  activities, 
defects  Injected  or  removed  In  a  particular  activity,  and  lessons  learned. 


Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  contributing  to  organizational  process  assets. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets. 

Subpractices 

1 .  Store  process  and  product  measures  in  the  organization’s 
measurement  repository. 

The  process  and  product  measures  are  primarily  those  measures  that  are  defined  in 
the  common  set  of  measures  for  the  organization’s  set  of  standard  processes. 

2.  Submit  documentation  for  inclusion  in  the  organization’s  process  asset 
library. 

3.  Document  lessons  learned  from  the  process  for  inclusion  in  the 
organization’s  process  asset  library. 

4.  Propose  improvements  to  the  organizational  process  assets. 

CAR  Elaboration 

;  Examples  of  process  related  experiences  include  the  following: 

;  •  Action  proposals 

i  •  Number  of  action  plans  that  are  open  and  for  how  long 
i  •  Action  plan  status  reports 


CM  Elaboration 

i  Examples  of  process  related  experiences  include  the  following: 
;  •  Trends  in  the  status  of  configuration  items 
I  •  Configuration  audit  results 

I  •  Change  request  aging  reports 


DAR  Elaboration 

I  Examples  process  related  experiences  include  the  following: 
:  •  Number  of  alternatives  considered 

I  •  Evaluation  results 

;  •  Recommended  solutions  to  address  significant  issues 
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IPM  Elaboration 

I  Examples  of  process  related  experiences  include  the  following: 

:  •  Project’s  defined  process 

I  •  Number  of  tailoring  options  exercised  by  the  project  to  create  its  defined  process 
;  •  Interface  coordination  issue  trends  (i.e.,  number  identified,  number  closed) 
i  •  Number  of  times  the  process  asset  library  is  accessed  for  assets  related  to  project 
I  planning  by  project  members 

I  •  Records  of  expenses  related  to  holding  face-to-face  meetings  versus  holding  meetings 
i  using  collaborative  equipment  such  as  teleconferencing  and  videoconferencing 

i  •  Project  shared  vision 

i  •  Team  charters 


MA  Elaboration 

i  Examples  of  process  related  experiences  include  the  following: 
i  •  Data  currency  status 
i  •  Results  of  data  integrity  tests 
j  •  Data  analysis  reports 


OPD  Elaboration 

I  Examples  of  process  related  experiences  include  the  following: 

I  •  Submission  of  lessons  learned  to  the  organization's  process  asset  library 

I  •  Submission  of  measurement  data  to  the  organization's  measurement  repository 

;  •  Status  of  the  change  requests  submitted  to  modify  the  organization's  standard  process 
i  •  Record  of  non-standard  tailoring  requests 


OPF  Elaboration 

:  Examples  of  process  related  experiences  include  the  following: 

i  •  Criteria  used  to  prioritize  candidate  process  improvements 
;  •  Appraisal  findings  that  address  strengths  and  weaknesses  of  the  organization's 
:  processes 

I  •  Status  of  improvement  activities  against  the  schedule 

;  •  Records  of  tailoring  the  organization’s  set  of  standard  processes  and  implementing 
i  them  on  identified  projects 
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OPM  Elaboration 

I  Examples  of  process  related  experiences  include  the  following: 

I  •  Lessons  learned  captured  from  analysis  of  process  performance  data  compared  to 
;  business  objectives 

i  •  Documented  measures  of  the  costs  and  benefits  resulting  from  implementing  and 

:  deploying  improvements 

I  •  Report  of  a  comparison  of  similar  development  processes  to  identify  the  potential  for 
i  improving  efficiency 


OPP  Elaboration 

;  Examples  of  process  related  experiences  include  the  following: 
i  •  Process  performance  baselines 

i  •  Percentage  of  measurement  data  that  is  rejected  because  of  inconsistencies  with  the 
I  process  performance  measurement  definitions 


OT  Elaboration 

I  Examples  of  process  related  experiences  include  the  following: 
:  •  Results  of  training  effectiveness  surveys 
I  •  Training  program  performance  assessment  results 

I  •  Course  evaluations 

i  •  Training  requirements  from  an  advisory  group 


PI  Elaboration 

;  Examples  of  process  related  experiences  include  the  following: 

i  •  Records  of  the  receipt  of  product  components,  exception  reports,  confirmation  of 
i  configuration  status,  and  results  of  readiness  checking 

I  •  Percentage  of  total  development  effort  spent  in  product  integration  (actual  to  date  plus 
;  estimate  to  complete) 

i  •  Defects  found  in  the  product  and  test  environment  during  product  integration 
;  •  Problem  reports  resulting  from  product  integration 


PMC  Elaboration 

i  Examples  of  process  related  experiences  include  the  following: 
;  •  Records  of  significant  deviations 
i  •  Criteria  for  what  constitutes  a  deviation 
:  •  Corrective  action  results 
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PP  Elaboration 

I  Examples  of  process  related  experiences  include  the  following: 
:  •  Project  data  library  structure 

I  •  Project  attribute  estimates 

;  •  Risk  impacts  and  probability  of  occurrence 

PPQA  Elaboration 

I  Examples  of  process  related  experiences  include  the  following: 

:  •  Evaluation  logs 

I  •  Quality  trends 

;  •  Noncompliance  reports 

i  •  Status  reports  of  corrective  actions 

i  •  Cost  of  quality  reports  for  the  project 


QPM  Elaboration 

;  Examples  of  process  related  experiences  include  the  following: 

i  •  Records  of  quantitative  management  data  from  the  project,  including  results  from  the 
I  periodic  review  of  the  process  performance  of  the  subprocesses  selected  for 
;  management  against  established  interim  objectives  of  the  project 

i  •  Suggested  improvements  to  process  performance  models 


RD  Elaboration 

:  Examples  of  process  related  experiences  include  the  following: 
i  •  List  of  the  requirements  for  a  product  that  are  found  to  be  ambiguous 
;  •  Number  of  requirements  introduced  at  each  phase  of  the  project  lifecycle 
i  •  Lessons  learned  from  the  requirements  allocation  process 


REQM  Elaboration 

i  Examples  of  process  related  experiences  include  the  following: 
i  •  Requirements  traceability  matrix 
:  •  Number  of  unfunded  requirements  changes  after  baselining 
;  •  Lessons  learned  in  resolving  ambiguous  requirements 


RSKM  Elaboration 

f - - - - - 

I  Examples  of  process  related  experiences  include  the  following: 

I  •  Risk  parameters 

I  •  Risk  categories 

i  •  Risk  status  reports 
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SAM  Elaboration 

I  Examples  of  process  related  experiences  include  the  following: 
:  •  Results  of  supplier  reviews 
I  •  Trade  studies  used  to  select  suppliers 
;  •  Revision  history  of  supplier  agreements 
i  •  Supplier  performance  reports 


TS  Elaboration 

;  Examples  of  process  related  experiences  include  the  following: 

i  •  Results  of  the  make,  buy,  or  reuse  analysis 
;  •  Design  defect  density 
i  •  Results  of  applying  new  methods  and  tools 


VAL  Elaboration 

i  Examples  of  process  related  experiences  include  the  following: 

i  •  Product  component  prototype 
:  •  Percentage  of  time  the  validation  environment  is  available 

I  •  Number  of  product  defects  found  through  validation  per  development  phase 

I  •  Validation  analysis  report 


VER  Elaboration 

I  Examples  of  process  related  experiences  include  the  following: 

I  •  Peer  review  records  that  include  conduct  time  and  average  preparation  time 
;  •  Number  of  product  defects  found  through  verification  per  development  phase 
i  •  Verification  and  analysis  report 


Applying  Generic  Practices 

Generic  practices  are  components  that  can  be  applied  to  all  process  areas. 
Think  of  generic  practices  as  reminders.  They  serve  the  purpose  of 
reminding  you  to  do  things  right  and  are  expected  model  components. 

For  example,  consider  the  generic  practice,  “Establish  and  maintain  the 
plan  for  performing  the  process”  (GP  2.2).  When  applied  to  the  Project 
Planning  process  area,  this  generic  practice  reminds  you  to  plan  the 
activities  involved  in  creating  the  plan  for  the  project.  When  applied  to  the 
Organizational  Training  process  area,  this  same  generic  practice  reminds 
you  to  plan  the  activities  involved  in  developing  the  skills  and  knowledge  of 
people  in  the  organization. 
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Process  Areas  that  Support  Generic  Practices 


While  generic  goals  and  generic  practices  are  the  model  components  that 
directly  address  the  institutionalization  of  a  process  across  the  organization, 
many  process  areas  likewise  address  institutionalization  by  supporting  the 
implementation  of  the  generic  practices.  Knowing  these  relationships  will 
help  you  effectively  implement  the  generic  practices. 

Such  process  areas  contain  one  or  more  specific  practices  that  when 
implemented  can  also  fully  implement  a  generic  practice  or  generate  a  work 
product  that  is  used  in  the  implementation  of  a  generic  practice. 

An  example  is  the  Configuration  Management  process  area  and  GP  2.6, 
“Place  selected  work  products  of  the  process  under  appropriate  levels  of 
control.”  To  implement  the  generic  practice  for  one  or  more  process  areas, 
you  might  choose  to  implement  the  Configuration  Management  process 
area,  all  or  in  part,  to  implement  the  generic  practice. 

Another  example  is  the  Organizational  Process  Definition  process  area  and 
GP  3.1,  “Establish  and  maintain  the  description  of  a  defined  process.”  To 
implement  this  generic  practice  for  one  or  more  process  areas,  you  should 
first  implement  the  Organizational  Process  Definition  process  area,  all  or  in 
part,  to  establish  the  organizational  process  assets  that  are  needed  to 
implement  the  generic  practice. 

Table  6.2  describes  (1)  the  process  areas  that  support  the  implementation 
of  generic  practices  and  (2)  the  recursive  relationships  between  generic 
practices  and  their  closely  related  process  areas.  Both  types  of 
relationships  are  important  to  remember  during  process  improvement  to 
take  advantage  of  the  natural  synergies  that  exist  between  the  generic 
practices  and  their  related  process  areas. 
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Table  6.2  Generic  Practice  and  Process  Area  Relationships 


Generic  Practice 

Roies  of  Process  Areas  in 

Impiementation  of  the  Generic  Practice 

How  the  Generic  Practice  Recursiveiy 
Appiies  to  its  Rotated  Process  Area(s)^^ 

GP2.2 

Plan  the  Process 

Project  Planning:  The  project  planning 
process  can  implement  GP  2.2  in  full  for 
all  project  related  process  areas  (except 
for  Project  Planning  itself). 

GP  2.2  applied  to  the  project  planning 
process  can  be  characterized  as  “plan 
the  plan”  and  covers  planning  project 
planning  activities. 

GP2.3 

Provide 

Resources 

GP2.4 

Assign 

Responsibility 

Project  Planning:  The  part  of  the 
project  planning  process  that 
implements  Project  Planning  SP  2.4, 

“Plan  the  Project’s  Resources,”  supports 
the  implementation  of  GP  2.3  and  GP 

2.4  for  all  project  related  process  areas 
(except  perhaps  initially  for  Project 
Planning  itself)  by  identifying  needed 
processes,  roles,  and  responsibilities  to 
ensure  the  proper  staffing,  facilities, 
equipment,  and  other  assets  needed  by 
the  project  are  secured. 

GP2.5 

Train  People 

Organizational  Training:  The 

organizational  training  process  supports 
the  implementation  of  GP  2.5  as  applied 
to  all  process  areas  by  making  the 
training  that  addresses  strategic  or 
organization-wide  training  needs 
available  to  those  who  will  perform  or 
support  the  process. 

GP  2.5  applied  to  the  organizational 
training  process  covers  training  for 
performing  the  organizational  training 
activities,  which  addresses  the  skills 
required  to  manage,  create,  and 
accomplish  the  training. 

Project  Planning:  The  part  of  the 
project  planning  process  that 
implements  Project  Planning  SP  2.5, 

“Plan  Needed  Knowledge  and  Skills,” 
and  the  organizational  training  process, 
supports  the  implementation  of  GP  2.5 
in  full  for  all  project  related  process 
areas. 

GP2.6 

Control  Work 
Products 

Configuration  Management:  The 

configuration  management  process  can 
implement  GP  2.6  in  full  for  all  project 
related  process  areas  as  well  as  some 
of  the  organizational  process  areas. 

GP  2.6  applied  to  the  configuration 
management  process  covers  change 
and  version  control  for  the  work 
products  produced  by  configuration 
management  activities. 

"  When  the  relationship  between  a  generic  practice  and  a  process  area  is  less  direct,  the  risk  of  confusion  is  reduced;  therefore, 
we  do  not  describe  all  recursive  relationships  in  the  table  (e.g.,  for  generic  practices  2.3,  2.4,  and  2.10). 
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Generic  Practice  Poies  of  Process  Areas  in  How  the  Generic  Practice  Recursiveiy 

Impiementation  of  the  Generic  Practice  Appiies  to  its  Reiated  Process  Area(sf' 


GP2.7 
Identify  and 
Involve  Relevant 
Stakeholders 


Project  Planning:  The  part  of  the 
project  planning  process  that 
implements  Project  Planning  SP  2.6, 
“Plan  Stakeholder  Involvement,”  can 
implement  the  stakeholder  identification 
part  (first  two  subpractices)  of  GP  2.7  in 
full  for  all  project  related  process  areas. 

Project  Monitoring  and  Control:  The 

part  of  the  project  monitoring  and  control 
process  that  implements  Project 
Monitoring  and  Control  SP  1.5,  “Monitor 
Stakeholder  Involvement,”  can  aid  in 
implementing  the  third  subpractice  of 
GP  2.7  for  all  project  related  process 
areas. 


GP  2.7  applied  to  the  project  planning 
process  covers  the  involvement  of 
relevant  stakeholders  in  project  planning 
activities. 

GP  2.7  applied  to  the  project  monitoring 
and  control  process  covers  the 
involvement  of  relevant  stakeholders  in 
project  monitoring  and  control  activities. 

GP  2.7  applied  to  the  integrated  project 
management  process  covers  the 
involvement  of  relevant  stakeholders  in 
integrated  project  management 
activities. 


Integrated  Project  Management:  The 

part  of  the  integrated  project 
management  process  that  implements 
Integrated  Project  Management  SP  2.1, 
“Manage  Stakeholder  Involvement,”  can 
aid  in  implementing  the  third  subpractice 
of  GP  2.7  for  all  project  related  process 
areas. 


GP2.8 
Monitor  and 
Control  the 
Process 


Project  Monitoring  and  Control:  The 

project  monitoring  and  control  process 
can  implement  GP  2.8  in  full  for  all 
project  related  process  areas. 

Measurement  and  Analysis:  For  all 

processes,  not  just  project  related 
processes,  the  Measurement  and 
Analysis  process  area  provides  general 
guidance  about  measuring,  analyzing, 
and  recording  information  that  can  be 
used  in  establishing  measures  for 
monitoring  performance  of  the  process. 


GP  2.8  applied  to  the  project  monitoring 
and  control  process  covers  the 
monitoring  and  controlling  of  the 
project’s  monitor  and  control  activities. 


GP  2.9 
Objectively 
Evaluate 
Adherence 


Process  and  Product  Quality 
Assurance:  The  process  and  product 
quality  assurance  process  can 
implement  GP  2.9  in  full  for  all  process 
areas  (except  perhaps  for  Process  and 
Product  Quality  Assurance  itself). 


GP  2.9  applied  to  the  process  and 
product  quality  assurance  process 
covers  the  objective  evaluation  of  quality 
assurance  activities  and  selected  work 
products. 
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Generic  Practice  Poies  of  Process  Areas  in  How  the  Generic  Practice  Recursiveiy 

Impiementation  of  the  Generic  Practice  Appiies  to  its  Reiated  Process  Area(s)^^ 


GP2.10 
Review  Status 
with  Higher  Level 
Management 


Project  Monitoring  and  Controi:  The 

part  of  the  project  monitoring  and  control 
process  that  implements  Project 
Monitoring  and  Control  SP  1.6,  “Conduct 
Progress  Reviews,”  and  SP  1.7, 
“Conduct  Milestone  Reviews,”  supports 
the  implementation  of  GP  2.10  for  all 
project  related  process  areas,  perhaps 
in  full,  depending  on  higher  level 
management  involvement  in  these 
reviews. 


GP  3.1 
Establish  a 
Defined  Process 


integrated  Project  Management:  The 

part  of  the  integrated  project 
management  process  that  implements 
Integrated  Project  Management  SP  1.1, 
“Establish  the  Project’s  Defined 
Process,”  can  implement  GP  3.1  in  full 
for  all  project  related  process  areas. 

Organizationai  Process  Definition: 

For  all  processes,  not  just  project  related 
processes,  the  organizational  process 
definition  process  establishes  the 
organizational  process  assets  needed  to 
implement  GP  3.1 . 


GP  3.1  applied  to  the  integrated  project 
management  process  covers 
establishing  defined  processes  for 
integrated  project  management 
activities. 


GP  3.2 

Collect  Process 

Related 

Experiences 


integrated  Project  Management:  The 

part  of  the  integrated  project 
management  process  that  implements 
Integrated  Project  Management  SP  1 .7, 
“Contribute  to  Organizational  Process 
Assets,”  can  implement  GP  3.2  in  part  or 
in  full  for  all  project  related  process 
areas. 

Organizational  Process  Focus:  The 

part  of  the  organizational  process  focus 
process  that  implements  Organizational 
Process  Focus  SP  3.4,  “Incorporate 
Experiences  into  Organizational  Process 
Assets,”  can  implement  GP  3.2  in  part  or 
in  full  for  all  process  areas. 

Organizational  Process  Definition: 

For  all  processes,  the  organizational 
process  definition  process  establishes 
the  organizational  process  assets 
needed  to  implement  GP  3.2. 


GP  3.2  applied  to  the  integrated  project 
management  process  covers  collecting 
process  related  experiences  derived 
from  planning  and  performing  integrated 
project  management  activities. 
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Given  the  dependencies  that  generic  practices  have  on  these  process 
areas,  and  given  the  more  holistic  view  that  many  of  these  process  areas 
provide,  these  process  areas  are  often  implemented  early,  in  whole  or  in 
part,  before  or  concurrent  with  implementing  the  associated  generic 
practices. 

There  are  also  a  few  situations  where  the  result  of  applying  a  generic 
practice  to  a  particular  process  area  would  seem  to  make  a  whole  process 
area  redundant,  but,  in  fact,  it  does  not.  It  can  be  natural  to  think  that 
applying  GP  3.1,  “Establish  a  Defined  Process,”  to  the  Project  Planning  and 
Project  Monitoring  and  Control  process  areas  gives  the  same  effect  as  the 
first  specific  goal  of  Integrated  Project  Management,  “Use  the  Project’s 
Defined  Process.” 

Although  it  is  true  that  there  is  some  overlap,  the  application  of  the  generic 
practice  to  these  two  process  areas  provides  defined  processes  covering 
project  planning  and  project  monitoring  and  control  activities.  These  defined 
processes  do  not  necessarily  cover  support  activities  (e.g.,  configuration 
management),  other  project  management  processes  (e.g.,  integrated 
project  management),  or  other  processes.  In  contrast,  the  project’s  defined 
process,  provided  by  the  Integrated  Project  Management  process  area, 
covers  all  appropriate  processes. 
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CAUSAL  ANALYSIS  AND  RESOLUTION 

A  Support  Process  Area  at  Maturity  Level  5 


Purpose 


The  purpose  of  Causal  Analysis  and  Resolution  (CAR)  is  to  identify  causes 
of  selected  outcomes  and  take  action  to  improve  process  performance. 


Introductory  Notes 


Causal  analysis  and  resolution  improves  quality  and  productivity  by 
preventing  the  introduction  of  defects  or  problems  and  by  identifying  and 
appropriately  incorporating  the  causes  of  superior  process  performance. 

The  Causal  Analysis  and  Resolution  process  area  involves  the  following 
activities: 

•  Identifying  and  analyzing  causes  of  selected  outcomes.  The  selected 
outcomes  can  represent  defects  and  problems  that  can  be  prevented 
from  happening  in  the  future  or  successes  that  can  be  implemented  in 
projects  or  the  organization. 

•  Taking  actions  to  complete  the  following: 

o  Remove  causes  and  prevent  the  recurrence  of  those  types  of 
defects  and  problems  in  the  future 

o  Proactively  analyze  data  to  identify  potential  problems  and  prevent 
them  from  occurring 

o  Incorporate  the  causes  of  successes  into  the  process  to  improve 
future  process  performance 

Reliance  on  detecting  defects  and  problems  after  they  have  been 
introduced  is  not  cost  effective.  It  is  more  effective  to  prevent  defects  and 
problems  by  integrating  Causal  Analysis  and  Resolution  activities  into  each 
phase  of  the  project. 

Since  similar  outcomes  may  have  been  previously  encountered  in  other 
projects  or  in  earlier  phases  or  tasks  of  the  current  project,  Causal  Analysis 
and  Resolution  activities  are  mechanisms  for  communicating  lessons 
learned  among  projects. 

Types  of  outcomes  encountered  are  analyzed  to  identify  trends.  Based  on 
an  understanding  of  the  defined  process  and  how  it  is  implemented,  root 
causes  of  these  outcomes  and  future  implications  of  them  are  determined. 

Since  it  is  impractical  to  perform  causal  analysis  on  all  outcomes,  targets 
are  selected  by  tradeoffs  on  estimated  investments  and  estimated  returns 
of  quality,  productivity,  and  cycle  time. 

Measurement  and  analysis  processes  should  already  be  in  place.  Existing 
defined  measures  can  be  used,  though  in  some  instances  new 
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measurement  definitions,  redefinitions,  or  clarified  definitions  may  be 
needed  to  analyze  the  effects  of  a  process  change. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  aligning  measurement  and  analysis  activities  and  providing 
measurement  results. 

Causal  Analysis  and  Resolution  activities  provide  a  mechanism  for  projects 
to  evaluate  their  processes  at  the  local  level  and  look  for  improvements  that 
can  be  implemented. 

When  improvements  are  judged  to  be  effective,  the  information  is  submitted 
to  the  organizational  level  for  potential  deployment  in  the  organizational 
processes. 

The  specific  practices  of  this  process  area  apply  to  a  process  that  is 
selected  for  quantitative  management.  Use  of  the  specific  practices  of  this 
process  area  can  add  value  in  other  situations,  but  the  results  may  not 
provide  the  same  degree  of  impact  to  the  organization’s  quality  and  process 
performance  objectives. 


Related  Process  Areas 


Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  aligning  measurement  and  analysis  activities  and  providing 
measurement  results. 

Refer  to  the  Organizational  Performance  Management  process  area  for 
more  information  about  selecting  and  implementing  improvements  for 
deployment. 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  quantitatively  managing  the  project  to  achieve  the 
project’s  established  quality  and  process  performance  objectives. 

Specific  Goal  and  Practice  Summary 

SG  1  Determine  Causes  of  Selected  Outcomes 
SP  1 .1  Select  Outcomes  for  Analysis 

SP  1 .2  Analyze  Causes 

SG  2  Address  Causes  of  Selected  Outcomes 
SP2.1  Implement  Action  Proposals 

SP  2.2  Evaluate  the  Effect  of  Implemented  Actions 
SP  2.3  Record  Causal  Analysis  Data 

Specific  Practices  by  Goal 


SG  1 _ Determine  Causes  of  Selected  Outcomes _ 

Root  causes  of  selected  outcomes  are  systematically  determined. 

A  root  cause  is  an  initiating  element  in  a  causal  chain  which  leads  to  an 
outcome  of  interest. 
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SP  1 .1  Select  Outcomes  for  Analysis 

Select  outcomes  for  analysis. 

This  activity  could  be  triggered  by  an  event  (reactive)  or  could  be  planned 
periodically,  such  as  at  the  beginning  of  a  new  phase  or  task  (proactive). 

Example  Work  Products 

1 .  Data  to  be  used  in  the  initial  analysis 

2.  Initial  analysis  results  data 

3.  Outcomes  selected  for  further  analysis 
Subpractices 

1 .  Gather  relevant  data. 

;  Examples  of  relevant  data  Include  the  following: 

;  •  Defects  reported  by  customers  or  end  users 
i  •  Defects  found  In  peer  reviews  or  testing 
I  •  Productivity  measures  that  are  higher  than  expected 
I  •  Project  management  problem  reports  requiring  corrective  action 
;  •  Process  capability  problems 

I  •  Earned  value  measurements  by  process  (e.g.,  cost  performance  Index) 

I  •  Resource  throughput,  utilization,  or  response  time  measurements 
I  •  Service  fulfillment  or  service  satisfaction  problems 

2.  Determine  which  outcomes  to  analyze  further. 

When  determining  which  outcomes  to  analyze  further,  consider  their  source,  impact, 
frequency  of  occurrence,  similarity,  the  cost  of  analysis,  the  time  and  resources 
needed,  safety  considerations,  etc. 

:  Examples  of  methods  for  selecting  outcomes  include  the  following: 

i  •  Pareto  analysis 
i  •  Histograms 

i  •  Box  and  whisker  plots  for  attributes 
i  •  Failure  mode  and  effects  analysis  (FMEA) 

;  •  Process  capability  analysis 

3.  Formally  define  the  scope  of  the  analysis,  including  a  clear  definition  of 
the  improvement  needed  or  expected,  stakeholders  affected,  target 
affected,  etc. 

Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai 
evaiuation  process  that  evaiuates  identified  aiternatives  against 
estabiished  criteria. 
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SP  1 .2  Analyze  Causes 

Perform  causal  analysis  of  selected  outcomes  and  propose  actions 
to  address  them. 

The  purpose  of  this  analysis  is  to  define  actions  that  will  address  selected 
outcomes  by  analyzing  relevant  outcome  data  and  producing  action 
proposals  for  implementation. 

Example  Work  Products 

1 .  Root  cause  analysis  results 

2.  Action  proposal 
Subpractices 

1 .  Conduct  causal  analysis  with  those  who  are  responsible  for  performing 
the  task. 

Causal  analysis  is  performed,  typically  in  meetings,  with  those  who  understand  the 
selected  outcome  under  study.  Those  who  have  the  best  understanding  of  the 
selected  outcome  are  typically  those  who  are  responsible  for  performing  the  task.  The 
analysis  is  most  effective  when  applied  to  real  time  data,  as  close  as  possible  to  the 
event  which  triggered  the  outcome. 

;  Examples  of  when  to  perform  causal  analysis  include  the  following: 

I  •  When  a  stable  subprocess  does  not  meet  its  specified  quality  and  process 
I  performance  objectives,  or  when  a  subprocess  needs  to  be  stabilized 

I  •  During  the  task,  if  and  when  problems  warrant  a  causal  analysis  meeting 
I  •  When  a  work  product  exhibits  an  unexpected  deviation  from  its  requirements 
I  •  When  more  defects  than  anticipated  escape  from  earlier  phases  to  the  current  phase 
I  •  When  process  performance  exceeds  expectations 
I  •  At  the  start  of  a  new  phase  or  task 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  performing  root  cause  anaiysis. 

2.  Analyze  selected  outcomes  to  determine  their  root  causes. 

Analysis  of  process  performance  baselines  and  models  can  aid  in  the  identification  of 
potential  root  causes. 

Depending  on  the  type  and  number  of  outcomes,  it  can  be  beneficial  to  look  at  the 
outcomes  in  several  ways  to  ensure  all  potential  root  causes  are  investigated. 
Consider  looking  at  individual  outcomes  as  well  as  grouping  the  outcomes. 

f. - - 

I  Examples  of  methods  to  determine  root  causes  include  the  following: 

I  •  Cause-and-effect  (fishbone)  diagrams 
I  •  Check  sheets 

L _ _ 

3.  Combine  selected  outcomes  into  groups  based  on  their  root  causes. 

In  some  cases,  outcomes  can  be  influenced  by  multiple  root  causes. 
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Examples  of  cause  groups  or  categories  include  the  following: 

•  Inadequate  training  and  skills 

•  Breakdown  of  communication 

•  Not  accounting  for  all  details  of  a  task 

•  Making  mistakes  in  manual  procedures  (e.g.,  keyboard  entry) 

•  Process  deficiency 


Where  appropriate,  look  for  trends  or  symptoms  in  or  across  groupings. 

4.  Create  an  action  proposal  that  documents  actions  to  be  taken  to 
prevent  the  future  occurrence  of  similar  outcomes  or  to  incorporate 
best  practices  into  processes. 

Process  performance  models  can  support  cost  benefit  analysis  of  action  proposals 
through  prediction  of  impacts  and  return  on  investment. 

i  Examples  of  proposed  preventative  actions  include  changes  to  the  following: 

;  •  The  process  in  question 
i  •  Training 
i  •  Tools 
I  •  Methods 
I  •  Work  products 


f. - 

I  Examples  of  incorporating  best  practices  include  the  following: 

I  •  Creating  activity  checklists,  which  reinforce  training  or  communications  related  to 
I  common  problems  and  techniques  for  preventing  them 

I  •  Changing  a  process  so  that  error-prone  steps  do  not  occur 
I  •  Automating  all  or  part  of  a  process 
I  •  Reordering  process  activities 

I  •  Adding  process  steps,  such  as  task  kickoff  meetings  to  review  common  problems  as 
I  well  as  actions  to  prevent  them 


An  action  proposal  usually  documents  the  following: 

•  Originator  of  the  action  proposal 

•  Description  of  the  outcome  to  be  addressed 

•  Description  of  the  cause 

•  Cause  category 

•  Phase  identified 

•  Description  of  the  action 

•  Time,  cost,  and  other  resources  required  to  implement  the  action  proposal 

•  Expected  benefits  from  implementing  the  action  proposal 

•  Estimated  cost  of  not  fixing  the  problem 

•  Action  proposal  category 
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SG  2 _ Address  Causes  of  Selected  Outcomes _ 

Root  causes  of  selected  outcomes  are  systematically  addressed. 

Projects  operating  according  to  a  well-defined  process  systematically 
analyze  where  improvements  are  needed  and  implement  process  changes 
to  address  root  causes  of  selected  outcomes. 

SP  2.1  Implement  Action  Proposals 

Implement  selected  action  proposals  developed  In  causal  analysis. 

Action  proposals  describe  tasks  necessary  to  address  root  causes  of 
analyzed  outcomes  to  prevent  or  reduce  the  occurrence  or  recurrence  of 
negative  outcomes,  or  incorporate  realized  successes.  Action  plans  are 
developed  and  implemented  for  selected  action  proposals.  Only  changes 
that  prove  to  be  of  value  should  be  considered  for  broad  implementation. 

Example  Work  Products 

1 .  Action  proposals  selected  for  implementation 

2.  Action  plans 
Subpractices 

1 .  Analyze  action  proposals  and  determine  their  priorities. 

;  Criteria  for  prioritizing  action  proposals  include  the  following: 

I  •  Implications  of  not  addressing  the  outcome 
;  •  Cost  to  Implement  process  Improvements  to  address  the  outcome 
;  •  Expected  Impact  on  quality 

Process  performance  models  can  be  used  to  help  Identify  Interactions  among  multiple 
action  proposals. 

2.  Select  action  proposals  to  be  implemented. 

Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai 
evaiuation  process  that  evaiuates  identified  aiternatives  against 
estabiished  criteria. 

3.  Create  action  plans  for  implementing  the  selected  action  proposals. 
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Examples  of  information  provided  in  an  action  plan  include  the  following: 

•  Person  responsible  for  implementation 

•  Detailed  description  of  the  improvement 

•  Description  of  the  affected  areas 

•  People  who  are  to  be  kept  informed  of  status 

•  Schedule 

•  Cost  expended 

•  Next  date  that  status  will  be  reviewed 

•  Rationale  for  key  decisions 

•  Description  of  implementation  actions 


4.  Implement  action  plans. 

To  implement  action  plans,  the  following  tasks  should  be  performed: 

•  Make  assignments. 

•  Coordinate  the  people  doing  the  work. 

•  Review  the  results. 

•  T rack  action  items  to  closure. 

Experiments  may  be  conducted  for  particularly  complex  changes. 

^ - 

I  Examples  of  experiments  include  the  following: 

I  •  Using  a  temporarily  modified  process 
I  •  Using  a  new  tool 


Actions  may  be  assigned  to  members  of  the  causal  analysis  team,  members  of  the 
project  team,  or  other  members  of  the  organization. 

5.  Look  for  similar  causes  that  may  exist  in  other  processes  and  work 
products  and  take  action  as  appropriate. 

SP  2.2  Evaluate  the  Effect  of  Implemented  Actions 

Evaluate  the  effect  of  implemented  actions  on  process 
performance. 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  seiecting  measures  and  anaiytic  techniques. 

Once  the  changed  process  is  deployed  across  the  project,  the  effect  of 
changes  is  evaluated  to  verify  that  the  process  change  has  improved 
process  performance. 

Example  Work  Products 

1 .  Analysis  of  process  performance  and  change  in  process  performance 
Subpractices 

1 .  Measure  and  analyze  the  change  in  process  performance  of  the 
project’s  affected  processes  or  subprocesses. 
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This  subpractice  determines  whether  the  seiected  change  has  positiveiy  influenced 
process  performance  and  by  how  much. 

An  exampie  of  a  change  in  the  process  performance  of  the  project’s  defined  design 
process  wouid  be  a  change  in  the  predicted  abiiity  of  the  design  to  meet  the  quaiity 
and  process  performance  objectives. 

Another  exampie  wouid  be  a  change  in  the  defect  density  of  the  design 
documentation,  as  statisticaiiy  measured  through  peer  reviews  before  and  after  the 
improvement  has  been  made.  On  a  statisticai  process  controi  chart,  this  change  in 
process  performance  wouid  be  represented  by  an  improvement  in  the  mean,  a 
reduction  in  variation,  or  both. 


Statisticai  and  other  quantitative  techniques  (e.g.,  hypothesis  testing)  can  be  used  to 
compare  the  before  and  after  baseiines  to  assess  the  statisticai  significance  of  the 
change. 

2.  Determine  the  impact  of  the  change  on  achieving  the  project’s  quality 
and  process  performance  objectives. 

This  subpractice  determines  whether  the  seiected  change  has  positiveiy  influenced  the 
abiiity  of  the  project  to  meet  its  quaiity  and  process  performance  objectives  by 
understanding  how  changes  in  the  process  performance  data  have  affected  the 
objectives.  Process  performance  modeis  can  aid  in  the  evaiuation  through  prediction 
of  impacts  and  return  on  investment. 

3.  Determine  and  document  appropriate  actions  if  the  process  or 
subprocess  improvements  did  not  result  in  expected  project  benefits. 

SP  2.3  Record  Causal  Analysis  Data 

Record  causal  analysis  and  resolution  data  for  use  across  projects 

and  the  organization. 


Example  Work  Products 

1 .  Causal  analysis  and  resolution  records 

2.  Organizational  improvement  proposals 
Subpractices 

1 .  Record  causal  analysis  data  and  make  the  data  available  so  that  other 
projects  can  make  appropriate  process  changes  and  achieve  similar 
results. 

Record  the  following: 

•  Data  on  outcomes  that  were  analyzed 

•  Rationale  for  decisions 

•  Action  proposals  from  causal  analysis  meetings 

•  Action  plans  resulting  from  action  proposals 

•  Cost  of  analysis  and  resolution  activities 

•  Measures  of  changes  to  the  process  performance  of  the  defined  process  resulting  from 
resolutions 
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2.  Submit  process  improvement  proposals  for  the  organization  when  the 
implemented  actions  are  effective  for  the  project  as  appropriate. 

When  improvements  are  judged  to  be  effective,  the  information  can  be  submitted  to 
the  organizational  level  for  potential  Inclusion  In  the  organizational  processes. 

Refer  to  the  Organizational  Performance  Management  process  area 
for  more  information  about  selecting  improvements. 
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CONFIGURATION  MANAGEMENT 

A  Support  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Configuration  Management  (CM)  is  to  establish  and 
maintain  the  integrity  of  work  products  using  configuration  identification, 
configuration  control,  configuration  status  accounting,  and  configuration 
audits. 


Introductory  Notes 


The  Configuration  Management  process  area  involves  the  following 
activities: 

•  Identifying  the  configuration  of  selected  work  products  that  compose 
baselines  at  given  points  in  time 

•  Controlling  changes  to  configuration  items 

•  Building  or  providing  specifications  to  build  work  products  from  the 
configuration  management  system 

•  Maintaining  the  integrity  of  baselines 

•  Providing  accurate  status  and  current  configuration  data  to  developers, 
end  users,  and  customers 

The  work  products  placed  under  configuration  management  include  the 
products  that  are  delivered  to  the  customer,  designated  internal  work 
products,  acquired  products,  tools,  and  other  items  used  in  creating  and 
describing  these  work  products.  (See  the  definition  of  “configuration 
management”  in  the  glossary.) 
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Examples  of  work  products  that  can  be  placed  under  configuration  management  Include  the 
following: 

•  Hardware  and  equipment 

•  Drawings 

•  Product  specifications 

•  Tool  configurations 

•  Code  and  libraries 

•  Compilers 

•  Test  tools  and  test  scripts 

•  Installation  logs 

•  Product  data  files 

•  Product  technical  publications 

•  Plans 

•  User  stories 

•  Iteration  backlogs 

•  Process  descriptions 

•  Requirements 

•  Architecture  documentation  and  design  data 

•  Product  line  plans,  processes,  and  core  assets 


Acquired  products  may  need  to  be  placed  under  configuration  management 
by  both  the  supplier  and  the  project.  Provisions  for  conducting  configuration 
management  should  be  established  in  supplier  agreements.  Methods  to 
ensure  that  data  are  complete  and  consistent  should  be  established  and 
maintained. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  establishing  supplier  agreements. 

Configuration  management  of  work  products  can  be  performed  at  several 
levels  of  granularity.  Configuration  items  can  be  decomposed  into 
configuration  components  and  configuration  units.  Only  the  term 
“configuration  item”  is  used  in  this  process  area.  Therefore,  in  these 
practices,  “configuration  item”  may  be  interpreted  as  “configuration 
component”  or  “configuration  unit”  as  appropriate.  (See  the  definition  of 
“configuration  item”  in  the  glossary.) 

Baselines  provide  a  stable  basis  for  the  continuing  evolution  of 
configuration  items. 

An  example  of  a  baseline  Is  an  approved  description  of  a  product  that  Includes  Internally 
consistent  versions  of  requirements,  requirement  traceability  matrices,  design,  discipline- 
specific  Items,  and  end-user  documentation. 


Baselines  are  added  to  the  configuration  management  system  as  they  are 
developed.  Changes  to  baselines  and  the  release  of  work  products  built 
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from  the  configuration  management  system  are  systematically  controlled 
and  monitored  via  the  configuration  control,  change  management,  and 
configuration  auditing  functions  of  configuration  management. 

This  process  area  applies  not  only  to  configuration  management  on  projects 
but  also  to  configuration  management  of  organizational  work  products  such 
as  standards,  procedures,  reuse  libraries,  and  other  shared  supporting 
assets. 

Configuration  management  is  focused  on  the  rigorous  control  of  the 
managerial  and  technical  aspects  of  work  products,  including  the  delivered 
product  or  service. 

This  process  area  covers  the  practices  for  performing  the  configuration 
management  function  and  is  applicable  to  all  work  products  that  are  placed 
under  configuration  management. 

For  product  lines,  configuration  management  involves  additional 
considerations  due  to  the  sharing  of  core  assets  across  the  products  in  the 
product  line  and  across  multiple  versions  of  core  assets  and  products.  (See 
the  definition  of  “product  line”  in  the  glossary.) 

In  Agile  environments,  configuration  management  (CM)  is  important  because  of  the  need  to 
support  frequent  change,  frequent  builds  (typically  daily),  multiple  baselines,  and  multiple 
CM  supported  workspaces  (e.g.,  for  individuals,  teams,  and  even  for  pair-programming). 
Agile  teams  may  get  bogged  down  if  the  organization  doesn’t:  1)  automate  CM  (e.g.,  build 
scripts,  status  accounting,  integrity  checking)  and  2)  implement  CM  as  a  single  set  of 
standard  services.  At  its  start,  an  Agile  team  should  identify  the  individual  who  will  be 
responsible  to  ensure  CM  is  implemented  correctly.  At  the  start  of  each  iteration,  CM  support 
needs  are  re-confirmed.  CM  is  carefully  integrated  into  the  rhythms  of  each  team  with  a 
focus  on  minimizing  team  distraction  to  get  the  job  done.  (See  “Interpreting  CMMI  When 
Using  Agile  Approaches”  in  Part  I.) 


Related  Process  Areas 


Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  monitoring  the  project  against  the  pian  and  managing 
corrective  action  to  ciosure. 

Refer  to  the  Project  Pianning  process  area  for  more  information  about 
deveioping  a  project  pian. 
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Specific  Goai  and  Practice  Summary 

SG  1  Establish  Baselines 

SP  1.1  Identify  Configuration  Items 

SP  1 .2  Establish  a  Configuration  Management  System 
SP  1 .3  Create  or  Release  Baselines 

SG  2  Track  and  Control  Changes 

SP  2.1  T rack  Change  Requests 

SP  2.2  Control  Configuration  Items 

SG  3  Establish  Integrity 

SP  3.1  Establish  Configuration  Management  Records 

SP  3.2  Perform  Configuration  Audits 

Specific  Practices  by  Goai 


SG  1  Establish  Baselines 

Baselines  of  identified  work  products  are  established. 

Specific  practices  to  establish  baselines  are  covered  by  this  specific  goal. 
The  specific  practices  under  the  Track  and  Control  Changes  specific  goal 
serve  to  maintain  the  baselines.  The  specific  practices  of  the  Establish 
Integrity  specific  goal  document  and  audit  the  integrity  of  the  baselines. 

SP  1.1  Identify  Configuration  Items 

Identify  configuration  items,  components,  and  related  work 
products  to  be  placed  under  configuration  management. 

Configuration  identification  is  the  selection  and  specification  of  the 
following: 

•  Products  delivered  to  the  customer 

•  Designated  internal  work  products 

•  Acquired  products 

•  Tools  and  other  capital  assets  of  the  project’s  work  environment 

•  Other  items  used  in  creating  and  describing  these  work  products 

Configuration  items  can  include  hardware,  equipment,  and  tangible  assets 
as  well  as  software  and  documentation.  Documentation  can  include 
requirements  specifications  and  interface  documents.  Other  documents  that 
serve  to  identify  the  configuration  of  the  product  or  service,  such  as  test 
results,  may  also  be  included. 

A  “configuration  item”  is  an  entity  designated  for  configuration  management, 
which  may  consist  of  multiple  related  work  products  that  form  a  baseline. 
This  logical  grouping  provides  ease  of  identification  and  controlled  access. 
The  selection  of  work  products  for  configuration  management  should  be 
based  on  criteria  established  during  planning. 

Example  Work  Products 

1 .  Identified  configuration  items 
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Subpractices 

1 .  Select  configuration  items  and  work  products  that  compose  them 
based  on  documented  criteria. 

:  Example  criteria  for  selecting  configuration  items  at  the  appropriate  work  product  level 
;  include  the  following: 

I  •  Work  products  that  can  be  used  by  two  or  more  groups 

I  •  Work  products  that  are  expected  to  change  over  time  either  because  of  errors  or 
I  changes  in  requirements 

I  •  Work  products  that  are  dependent  on  each  other  (i.e.,  a  change  in  one  mandates  a 
I  change  in  the  others) 

•  Work  products  critical  to  project  success 

:  Examples  of  work  products  that  may  be  part  of  a  configuration  item  include  the 
;  following: 

I  •  Design 

I  •  Test  plans  and  procedures 

I  •  Test  results 

I  •  Interface  descriptions 

I  •  Drawings 

I  •  Source  code 

I  •  User  stories  or  story  cards 

i  •  The  declared  business  case,  logic,  or  value 

i  •  Tools  (e.g.,  compilers) 

i  •  Process  descriptions 

;  •  Requirements 

2.  Assign  unique  identifiers  to  configuration  items. 

3.  Specify  the  important  characteristics  of  each  configuration  item. 

i  Example  characteristics  of  configuration  items  include  author,  document  or  file  type, 

I  programming  language  for  software  code  files,  minimum  marketable  features,  and  the 
i  purpose  the  configuration  item  serves. 


4.  Specify  when  each  configuration  item  is  placed  under  configuration 
management. 

i  Example  criteria  for  determining  when  to  place  work  products  under  configuration 
;  management  include  the  following: 

I  •  When  the  work  product  is  ready  for  test 
I  •  Stage  of  the  project  lifecycle 
:  •  Degree  of  control  desired  on  the  work  product 
j  •  Cost  and  schedule  limitations 
•  Stakeholder  requirements 

5.  Identify  the  owner  responsible  for  each  configuration  item. 
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6.  Specify  relationships  among  configuration  items. 

Incorporating  the  types  of  relationships  (e.g.,  parent-child,  dependency)  that  exist 
among  configuration  items  into  the  configuration  management  structure  (e.g., 
configuration  management  database)  assists  in  managing  the  effects  and  impacts  of 
changes. 

SP  1.2  Establish  a  Configuration  Management  System 

Establish  and  maintain  a  configuration  management  and  change 
management  system  for  controlling  work  products. 

A  configuration  management  system  includes  the  storage  media, 
procedures,  and  tools  for  accessing  the  system.  A  configuration 
management  system  can  consist  of  multiple  subsystems  with  different 
implementations  that  are  appropriate  for  each  configuration  management 
environment. 

A  change  management  system  includes  the  storage  media,  procedures, 
and  tools  for  recording  and  accessing  change  requests. 

Example  Work  Products 

1 .  Configuration  management  system  with  controlled  work  products 

2.  Configuration  management  system  access  control  procedures 

3.  Change  request  database 
Subpractices 

1 .  Establish  a  mechanism  to  manage  multiple  levels  of  control. 

The  level  of  control  is  typically  selected  based  on  project  objectives,  risk,  and 
resources.  Control  levels  can  vary  in  relation  to  the  project  lifecycle,  type  of  system 
under  development,  and  specific  project  requirements. 

i  Example  levels  of  control  include  the  following: 

i  •  Uncontrolled:  Anyone  can  make  changes, 
i  •  Work-in-progress:  Authors  control  changes. 

;  •  Released:  A  designated  authority  authorizes  and  controls  changes  and  relevant 
i  stakeholders  are  notified  when  changes  are  made. 


Levels  of  control  can  range  from  informal  control  that  simply  tracks  changes  made 
when  configuration  items  are  being  developed  to  formal  configuration  control  using 
baselines  that  can  only  be  changed  as  part  of  a  formal  configuration  management 
process. 

2.  Provide  access  control  to  ensure  authorized  access  to  the 
configuration  management  system. 

3.  Store  and  retrieve  configuration  items  in  a  configuration  management 
system. 

4.  Share  and  transfer  configuration  items  between  control  levels  in  the 
configuration  management  system. 
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5.  Store  and  recover  archived  versions  of  configuration  items. 

6.  Store,  update,  and  retrieve  configuration  management  records. 

7.  Create  configuration  management  reports  from  the  configuration 
management  system. 

8.  Preserve  the  contents  of  the  configuration  management  system. 

f. - 

I  Examples  of  preservation  functions  of  the  configuration  management  system  include 
;  the  following: 

i  •  Backup  and  restoration  of  configuration  management  files 
i  •  Archive  of  configuration  management  files 
I  •  Recovery  from  configuration  management  errors 

9.  Revise  the  configuration  management  structure  as  necessary. 

SP  1 .3  Create  or  Release  Baselines 

Create  or  release  baselines  for  internal  use  and  for  delivery  to  the 
customer. 

A  baseline  is  represented  by  the  assignment  of  an  identifier  to  a 
configuration  item  or  a  collection  of  configuration  items  and  associated 
entities  at  a  distinct  point  in  time.  As  a  product  or  service  evolves,  multiple 
baselines  can  be  used  to  control  development  and  testing.  (See  the 
definition  of  “baseline”  in  the  glossary.) 

Hardware  products  as  well  as  software  and  documentation  should  also  be 
included  in  baselines  for  infrastructure  related  configurations  (e.g.,  software, 
hardware)  and  in  preparation  for  system  tests  that  include  interfacing 
hardware  and  software. 

One  common  set  of  baselines  includes  the  system  level  requirements, 
system  element  level  design  requirements,  and  the  product  definition  at  the 
end  of  development/beginning  of  production.  These  baselines  are  typically 
referred  to  respectively  as  the  “functional  baseline,”  “allocated  baseline,” 
and  “product  baseline.” 

A  software  baseline  can  be  a  set  of  requirements,  design,  source  code  files 
and  the  associated  executable  code,  build  files,  and  user  documentation 
(associated  entities)  that  have  been  assigned  a  unique  identifier. 

Example  Work  Products 

1.  Baselines 

2.  Description  of  baselines 
Subpractices 

1 .  Obtain  authorization  from  the  CCB  before  creating  or  releasing 
baselines  of  configuration  items. 

2.  Create  or  release  baselines  only  from  configuration  items  in  the 
configuration  management  system. 


Configuration  Management  (CM) 


143 


CMMI  for  Development,  Version  1.3 


3.  Document  the  set  of  configuration  items  that  are  contained  in  a 
baseline. 

4.  Make  the  current  set  of  baselines  readily  available. 

SG  2  Track  and  Control  Changes 

Changes  to  the  work  products  under  configuration  management  are  tracked 
and  controiied. 

The  specific  practices  under  this  specific  goal  serve  to  maintain  baselines 
after  they  are  established  by  specific  practices  under  the  Establish 
Baselines  specific  goal. 

SP  2.1  Track  Change  Requests 

Track  change  requests  for  configuration  items. 

Change  requests  address  not  only  new  or  changed  requirements  but  also 
failures  and  defects  in  work  products. 

Change  requests  are  analyzed  to  determine  the  impact  that  the  change  will 
have  on  the  work  product,  related  work  products,  the  budget,  and  the 
schedule. 

Example  Work  Products 

1 .  Change  requests 

Subpractices 

1 .  Initiate  and  record  change  requests  in  the  change  request  database. 

2.  Analyze  the  impact  of  changes  and  fixes  proposed  in  change  requests. 

Changes  are  evaluated  through  activities  that  ensure  that  they  are  consistent  with  all 
technical  and  project  requirements. 

Changes  are  evaluated  for  their  impact  beyond  immediate  project  or  contract 
requirements.  Changes  to  an  item  used  in  multiple  products  can  resolve  an  immediate 
issue  while  causing  a  problem  in  other  applications. 

Changes  are  evaluated  for  their  impact  on  release  plans. 

3.  Categorize  and  prioritize  change  requests. 

Emergency  requests  are  identified  and  referred  to  an  emergency  authority  if 
appropriate. 

Changes  are  allocated  to  future  baselines. 

4.  Review  change  requests  to  be  addressed  in  the  next  baseline  with 
relevant  stakeholders  and  get  their  agreement. 

Conduct  the  change  request  review  with  appropriate  participants.  Record  the 
disposition  of  each  change  request  and  the  rationale  for  the  decision,  including 
success  criteria,  a  brief  action  plan  if  appropriate,  and  needs  met  or  unmet  by  the 
change.  Perform  the  actions  required  in  the  disposition  and  report  results  to  relevant 
stakeholders. 

5.  Track  the  status  of  change  requests  to  closure. 
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Change  requests  brought  into  the  system  should  be  handled  in  an  efficient  and  timely 
manner.  Once  a  change  request  has  been  processed,  it  is  critical  to  close  the  request 
with  the  appropriate  approved  action  as  soon  as  it  is  practical.  Actions  left  open  result 
in  larger  than  necessary  status  lists,  which  in  turn  result  in  added  costs  and  confusion. 

SP  2.2  Control  Configuration  Items 

Control  changes  to  configuration  items. 

Control  is  maintained  over  the  configuration  of  the  work  product  baseline. 

This  control  includes  tracking  the  configuration  of  each  configuration  item, 

approving  a  new  configuration  if  necessary,  and  updating  the  baseline. 

Example  Work  Products 

1 .  Revision  history  of  configuration  items 

2.  Archives  of  baselines 

Subpractices 

1 .  Control  changes  to  configuration  items  throughout  the  life  of  the 
product  or  service. 

2.  Obtain  appropriate  authorization  before  changed  configuration  items 
are  entered  into  the  configuration  management  system. 

;  For  example,  authorization  can  come  from  the  CCB,  the  project  manager,  product 

i  owner,  or  the  customer. 

I _ 

3.  Check  in  and  check  out  configuration  items  in  the  configuration 
management  system  for  incorporation  of  changes  in  a  manner  that 
maintains  the  correctness  and  integrity  of  configuration  items. 

;  Examples  of  check-in  and  check-out  steps  include  the  following: 

;  •  Confirming  that  the  revisions  are  authorized 

i  •  Updating  the  configuration  items 

I  •  Archiving  the  replaced  baseline  and  retrieving  the  new  baseline 

I  •  Commenting  on  the  changes  made  to  the  item 

;  •  Tying  changes  to  related  work  products  such  as  requirements,  user  stories,  and  tests 

4.  Perform  reviews  to  ensure  that  changes  have  not  caused  unintended 
effects  on  the  baselines  (e.g.,  ensure  that  changes  have  not 
compromised  the  safety  or  security  of  the  system). 

5.  Record  changes  to  configuration  items  and  reasons  for  changes  as 
appropriate. 

If  a  proposed  change  to  the  work  product  is  accepted,  a  schedule  is  identified  for 
incorporating  the  change  into  the  work  product  and  other  affected  areas. 

Configuration  control  mechanisms  can  be  tailored  to  categories  of  changes.  For 
example,  the  approval  considerations  could  be  less  stringent  for  component  changes 
that  do  not  affect  other  components. 
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Changed  configuration  items  are  released  after  review  and  approval  of  configuration 
changes.  Changes  are  not  official  until  they  are  released. 

SG  3 _ Establish  Integrity _ 

Integrity  of  baselines  Is  established  and  maintained. 

The  integrity  of  baselines,  established  by  processes  associated  with  the 
Establish  Baselines  specific  goal,  and  maintained  by  processes  associated 
with  the  Track  and  Control  Changes  specific  goal,  is  addressed  by  the 
specific  practices  under  this  specific  goal. 

SP  3.1  Establish  Configuration  Management  Records 

Establish  and  maintain  records  describing  configuration  items. 


Example  Work  Products 

1 .  Revision  history  of  configuration  items 

2.  Change  log 

3.  Change  request  records 

4.  Status  of  configuration  items 

5.  Differences  between  baselines 
Subpractices 

1 .  Record  configuration  management  actions  in  sufficient  detail  so  the 
content  and  status  of  each  configuration  item  is  known  and  previous 
versions  can  be  recovered. 

2.  Ensure  that  relevant  stakeholders  have  access  to  and  knowledge  of 
the  configuration  status  of  configuration  items. 

I  Examples  of  activities  for  communicating  configuration  status  include  the  following: 

:  •  Providing  access  permissions  to  authorized  end  users 
i  •  Making  baseline  copies  readily  available  to  authorized  end  users 

i  •  Automatically  alerting  relevant  stakeholders  when  items  are  checked  in  or  out  or 
;  changed,  or  of  decisions  made  regarding  change  requests 

3.  Specify  the  latest  version  of  baselines. 

4.  Identify  the  version  of  configuration  items  that  constitute  a  particular 
baseline. 

5.  Describe  differences  between  successive  baselines. 

6.  Revise  the  status  and  history  (i.e.,  changes,  other  actions)  of  each 
configuration  item  as  necessary. 

SP  3.2  Perform  Configuration  Audits 

Perform  configuration  audits  to  maintain  the  integrity  of 
configuration  baselines. 
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Configuration  audits  confirm  that  the  resulting  baselines  and  documentation 
conform  to  a  specified  standard  or  requirement.  Configuration  item  related 
records  can  exist  in  multiple  databases  or  configuration  management 
systems.  In  such  instances,  configuration  audits  should  extend  to  these 
other  databases  as  appropriate  to  ensure  accuracy,  consistency,  and 
completeness  of  configuration  item  information.  (See  the  definition  of 
“configuration  audit”  in  the  glossary.) 

;  Examples  of  audit  types  include  the  following: 

I  •  Functional  configuration  audits  (FCAs):  Audits  conducted  to  verify  that  the  development 

;  of  a  configuration  item  has  been  completed  satisfactorily,  that  the  item  has  achieved  the 

I  functional  and  quality  attribute  characteristics  specified  in  the  functional  or  allocated 

i  baseline,  and  that  its  operational  and  support  documents  are  complete  and  satisfactory. 

;  •  Physical  configuration  audits  (PCAs):  Audits  conducted  to  verify  that  a  configuration 
:  item,  as  built,  conforms  to  the  technical  documentation  that  defines  and  describes  it. 

I  •  Configuration  management  audits:  Audits  conducted  to  confirm  that  configuration 
i  management  records  and  configuration  items  are  complete,  consistent,  and  accurate. 


Example  Work  Products 

1 .  Configuration  audit  results 

2.  Action  items 

Subpractices 

1 .  Assess  the  integrity  of  baselines. 

2.  Confirm  that  configuration  management  records  correctly  identify 
configuration  items. 

3.  Review  the  structure  and  integrity  of  items  in  the  configuration 
management  system. 

4.  Confirm  the  completeness,  correctness,  and  consistency  of  items  in 
the  configuration  management  system. 

Completeness,  correctness,  and  consistency  of  the  configuration  management 
system’s  content  are  based  on  requirements  as  stated  in  the  plan  and  the  disposition 
of  approved  change  requests. 

5.  Confirm  compliance  with  applicable  configuration  management 
standards  and  procedures. 

6.  Track  action  items  from  the  audit  to  closure. 
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DECISION  ANALYSIS  AND  RESOLUTION 

A  Support  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Decision  Analysis  and  Resolution  (DAR)  is  to  analyze 
possible  decisions  using  a  formal  evaluation  process  that  evaluates 
identified  alternatives  against  established  criteria. 


Introductory  Notes 


The  Decision  Analysis  and  Resolution  process  area  involves  establishing 
guidelines  to  determine  which  issues  should  be  subject  to  a  formal 
evaluation  process  and  applying  formal  evaluation  processes  to  these 
issues. 

A  formal  evaluation  process  is  a  structured  approach  to  evaluating 
alternative  solutions  against  established  criteria  to  determine  a 
recommended  solution. 

A  formal  evaluation  process  involves  the  following  actions: 

•  Establishing  the  criteria  for  evaluating  alternatives 

•  Identifying  alternative  solutions 

•  Selecting  methods  for  evaluating  alternatives 

•  Evaluating  alternative  solutions  using  established  criteria  and  methods 

•  Selecting  recommended  solutions  from  alternatives  based  on 
evaluation  criteria 

Rather  than  using  the  phrase  “alternative  solutions  to  address  issues”  each 
time,  in  this  process  area,  one  of  two  shorter  phrases  are  used:  “alternative 
solutions”  or  “alternatives.” 

A  formal  evaluation  process  reduces  the  subjective  nature  of  a  decision  and 
provides  a  higher  probability  of  selecting  a  solution  that  meets  multiple 
demands  of  relevant  stakeholders. 

While  the  primary  application  of  this  process  area  is  to  technical  concerns, 
formal  evaluation  processes  can  be  applied  to  many  nontechnical  issues, 
particularly  when  a  project  is  being  planned.  Issues  that  have  multiple 
alternative  solutions  and  evaluation  criteria  lend  themselves  to  a  formal 
evaluation  process. 

;  Trade  studies  of  equipment  or  software  are  typical  examples  of  formal  evaluation  processes. 


During  planning,  specific  issues  requiring  a  formal  evaluation  process  are 
identified.  Typical  issues  include  selection  among  architectural  or  design 
alternatives,  use  of  reusable  or  commercial  off-the-shelf  (COTS) 
components,  supplier  selection,  engineering  support  environments  or 
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associated  tools,  test  environments,  delivery  alternatives,  and  logistics  and 
production.  A  formal  evaluation  process  can  also  be  used  to  address  a 
make-or-buy  decision,  the  development  of  manufacturing  processes,  the 
selection  of  distribution  locations,  and  other  decisions. 

Guidelines  are  created  for  deciding  when  to  use  formal  evaluation 
processes  to  address  unplanned  issues.  Guidelines  often  suggest  using 
formal  evaluation  processes  when  issues  are  associated  with  medium-to- 
high-impact  risks  or  when  issues  affect  the  ability  to  achieve  project 
objectives. 

Defining  an  issue  well  helps  to  define  the  scope  of  alternatives  to  be 
considered.  The  right  scope  (i.e.,  not  too  broad,  not  too  narrow)  will  aid  in 
making  an  appropriate  decision  for  resolving  the  defined  issue. 

Formal  evaluation  processes  can  vary  in  formality,  type  of  criteria,  and 
methods  employed.  Less  formal  decisions  can  be  analyzed  in  a  few  hours, 
use  few  criteria  (e.g.,  effectiveness,  cost  to  implement),  and  result  in  a  one- 
or  two-page  report.  More  formal  decisions  can  require  separate  plans, 
months  of  effort,  meetings  to  develop  and  approve  criteria,  simulations, 
prototypes,  piloting,  and  extensive  documentation. 

Both  numeric  and  non-numeric  criteria  can  be  used  in  a  formal  evaluation 
process.  Numeric  criteria  use  weights  to  reflect  the  relative  importance  of 
criteria.  Non-numeric  criteria  use  a  subjective  ranking  scale  (e.g.,  high, 
medium,  low).  More  formal  decisions  can  require  a  full  trade  study. 

A  formal  evaluation  process  identifies  and  evaluates  alternative  solutions. 
The  eventual  selection  of  a  solution  can  involve  iterative  activities  of 
identification  and  evaluation.  Portions  of  identified  alternatives  can  be 
combined,  emerging  technologies  can  change  alternatives,  and  the 
business  situation  of  suppliers  can  change  during  the  evaluation  period. 

A  recommended  alternative  is  accompanied  by  documentation  of  selected 
methods,  criteria,  alternatives,  and  rationale  for  the  recommendation.  The 
documentation  is  distributed  to  relevant  stakeholders;  it  provides  a  record  of 
the  formal  evaluation  process  and  rationale,  which  are  useful  to  other 
projects  that  encounter  a  similar  issue. 

While  some  of  the  decisions  made  throughout  the  life  of  the  project  involve 
the  use  of  a  formal  evaluation  process,  others  do  not.  As  mentioned  earlier, 
guidelines  should  be  established  to  determine  which  issues  should  be 
subject  to  a  formal  evaluation  process. 

Related  Process  Areas 


Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  analyzing  risks  and  mitigating  risks. 
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Specific  Goai  and  Practice  Summary 

SG  1  Evaluate  Alternatives 

SP  1 .1  Establish  Guidelines  for  Decision  Analysis 

SP  1.2  Establish  Evaluation  Criteria 

SP  1 .3  Identify  Alternative  Solutions 

SP  1 .4  Select  Evaluation  Methods 

SP  1 .5  Evaluate  Alternative  Solutions 

SP1.6  Select  Solutions 


Specific  Practices  by  Goai 


SG  1  Evaluate  Alternatives 

Decisions  are  based  on  an  evaiuation  of  aiternatives  using  estabiished 
criteria. 

Issues  requiring  a  formal  evaluation  process  can  be  identified  at  any  time. 
The  objective  should  be  to  identify  issues  as  early  as  possible  to  maximize 
the  time  available  to  resolve  them. 

SP  1.1  Establish  Guidelines  for  Decision  Analysis 

Estabiish  and  maintain  guideiines  to  determine  which  issues  are 
subject  to  a  format  evaiuation  process. 

Not  every  decision  is  significant  enough  to  require  a  formal  evaluation 
process.  The  choice  between  the  trivial  and  the  truly  important  is  unclear 
without  explicit  guidance.  Whether  a  decision  is  significant  or  not  is 
dependent  on  the  project  and  circumstances  and  is  determined  by 
established  guidelines. 

;  Typical  guidelines  for  determining  when  to  require  a  formal  evaluation  process  include  the 
i  following: 

i  •  A  decision  is  directly  related  to  issues  that  are  medium-to-high-impact  risk. 

:  •  A  decision  is  related  to  changing  work  products  under  configuration  management. 

I  •  A  decision  would  cause  schedule  delays  over  a  certain  percentage  or  amount  of  time. 

;  •  A  decision  affects  the  ability  of  the  project  to  achieve  its  objectives. 

i  •  The  costs  of  the  formal  evaluation  process  are  reasonable  when  compared  to  the 
i  decision’s  impact. 

I  •  A  legal  obligation  exists  during  a  solicitation. 

I  •  When  competing  quality  attribute  requirements  would  result  in  significantly  different 
i  alternative  architectures. 


Refer  to  the  Risk  Management  process  area  for  more  information  about 
evaiuating,  categorizing,  and  prioritizing  risks. 
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Examples  of  activities  for  which  you  may  use  a  formal  evaluation  process  include  the 

following: 

•  Making  decisions  involving  the  procurement  of  material  when  20  percent  of  the  material 
parts  constitute  80  percent  of  the  total  material  costs 

•  Making  design-implementation  decisions  when  technical  performance  failure  can  cause 
a  catastrophic  failure  (e.g.,  safety-of-flight  item) 

•  Making  decisions  with  the  potential  to  significantly  reduce  design  risk,  engineering 
changes,  cycle  time,  response  time,  and  production  costs  (e.g.,  to  use  lithography 
models  to  assess  form  and  fit  capability  before  releasing  engineering  drawings  and 
production  builds) 


Example  Work  Products 

1 .  Guidelines  for  when  to  apply  a  formal  evaluation  process 
Subpractices 

1 .  Establish  guidelines  for  when  to  use  a  formal  evaluation  process. 

2.  Incorporate  the  use  of  guidelines  into  the  defined  process  as 
appropriate. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process. 

SP  1.2  Establish  Evaluation  Criteria 

Establish  and  maintain  criteria  for  evaluating  alternatives  and  the 
relative  ranking  of  these  criteria. 

Evaluation  criteria  provide  the  basis  for  evaluating  alternative  solutions. 
Criteria  are  ranked  so  that  the  highest  ranked  criteria  exert  the  most 
influence  on  the  evaluation. 

This  process  area  is  referenced  by  many  other  process  areas  in  the  model, 
and  many  contexts  in  which  a  formal  evaluation  process  can  be  used. 
Therefore,  in  some  situations  you  may  find  that  criteria  have  already  been 
defined  as  part  of  another  process.  This  specific  practice  does  not  suggest 
that  a  second  development  of  criteria  be  conducted. 

A  well-defined  statement  of  the  issue  to  be  addressed  and  the  decision  to 
be  made  focuses  the  analysis  to  be  performed.  Such  a  statement  also  aids 
in  defining  evaluation  criteria  that  minimize  the  possibility  that  decisions  will 
be  second  guessed  or  that  the  reason  for  making  the  decision  will  be 
forgotten.  Decisions  based  on  criteria  that  are  explicitly  defined  and 
established  remove  barriers  to  stakeholder  buy-in. 

Example  Work  Products 

1 .  Documented  evaluation  criteria 

2.  Rankings  of  criteria  importance 
Subpractices 

1 .  Define  the  criteria  for  evaluating  alternative  solutions. 


152 


Decision  Analysis  and  Resolution  (DAR) 


CMMI  for  Development,  Version  1.3 


Criteria  shouid  be  traceabie  to  requirements,  scenarios,  business  case  assumptions, 
business  objectives,  or  other  documented  sources. 

Types  of  criteria  to  consider  inciude  the  foiiowing: 

•  Technology  limitations 

•  Environmental  impact 

•  Risks 

•  Business  value 

•  Impact  on  priorities 

•  Total  ownership  and  lifecycle  costs 


2.  Define  the  range  and  scale  for  ranking  the  evaluation  criteria. 

Scales  of  relative  importance  for  evaluation  criteria  can  be  established  with  non¬ 
numeric  values  or  with  formulas  that  relate  the  evaluation  parameter  to  a  numeric 
weight. 

3.  Rank  the  criteria. 

The  criteria  are  ranked  according  to  the  defined  range  and  scale  to  reflect  the  needs, 
objectives,  and  priorities  of  the  relevant  stakeholders. 

4.  Assess  the  criteria  and  their  relative  importance. 

5.  Evolve  the  evaluation  criteria  to  improve  their  validity. 

6.  Document  the  rationale  for  the  selection  and  rejection  of  evaluation 
criteria. 

Documentation  of  selection  criteria  and  rationale  may  be  needed  to  justify  solutions  or 
for  future  reference  and  use. 

SP  1 .3  Identify  Alternative  Solutions 

Identify  alternative  solutions  to  address  Issues. 

A  wider  range  of  alternatives  can  surface  by  soliciting  as  many  stakeholders 
as  practical  for  input.  Input  from  stakeholders  with  diverse  skills  and 
backgrounds  can  help  teams  identify  and  address  assumptions,  constraints, 
and  biases.  Brainstorming  sessions  can  stimulate  innovative  alternatives 
through  rapid  interaction  and  feedback. 

Sufficient  candidate  solutions  may  not  be  furnished  for  analysis.  As  the 
analysis  proceeds,  other  alternatives  should  be  added  to  the  list  of  potential 
candidate  solutions.  The  generation  and  consideration  of  multiple 
alternatives  early  in  a  decision  analysis  and  resolution  process  increases 
the  likelihood  that  an  acceptable  decision  will  be  made  and  that 
consequences  of  the  decision  will  be  understood. 

Example  Work  Products 

1 .  Identified  alternatives 

Subpractices 

1 .  Perform  a  literature  search. 
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A  literature  search  can  uncover  what  others  have  done  both  inside  and  outside  the 
organization.  Such  a  search  can  provide  a  deeper  understanding  of  the  problem, 
alternatives  to  consider,  barriers  to  implementation,  existing  trade  studies,  and  lessons 
learned  from  similar  decisions. 

2.  Identify  alternatives  for  consideration  in  addition  to  the  alternatives  that 
may  be  provided  with  the  issue. 

Evaluation  criteria  are  an  effective  starting  point  for  identifying  alternatives.  Evaluation 
criteria  identify  priorities  of  relevant  stakeholders  and  the  importance  of  technical, 
logistical,  or  other  challenges. 

Combining  key  attributes  of  existing  alternatives  can  generate  additional  and 
sometimes  stronger  alternatives. 

Solicit  alternatives  from  relevant  stakeholders.  Brainstorming  sessions,  interviews,  and 
working  groups  can  be  used  effectively  to  uncover  alternatives. 

3.  Document  proposed  alternatives. 

SP  1 .4  Select  Evaluation  Methods 

Select  evaluation  methods. 

Methods  for  evaluating  alternative  solutions  against  established  criteria  can 
range  from  simulations  to  the  use  of  probabilistic  models  and  decision 
theory.  These  methods  should  be  carefully  selected.  The  level  of  detail  of  a 
method  should  be  commensurate  with  cost,  schedule,  performance,  and 
risk  impacts. 

While  many  problems  may  require  only  one  evaluation  method,  some 
problems  may  require  multiple  methods.  For  example,  simulations  may 
augment  a  trade  study  to  determine  which  design  alternative  best  meets  a 
given  criterion. 

Example  Work  Products 

1 .  Selected  evaluation  methods 

Subpractices 

1 .  Select  methods  based  on  the  purpose  for  analyzing  a  decision  and  on 
the  availability  of  the  information  used  to  support  the  method. 

i  For  example,  the  methods  used  for  evaluating  a  solution  when  requirements  are 
I  weakly  defined  may  be  different  from  the  methods  used  when  the  requirements  are 
i  well  defined. 
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Typical  evaluation  methods  include  the  following: 

•  Testing 

•  Modeling  and  simulation 

•  Engineering  studies 

•  Manufacturing  studies 

•  Cost  studies 

•  Business  opportunity  studies 

•  Surveys 

•  Extrapolations  based  on  field  experience  and  prototypes 

•  End-user  review  and  comment 

•  Judgment  provided  by  an  expert  or  group  of  experts  (e.g.,  Delphi  method) 


2.  Select  evaluation  methods  based  on  their  ability  to  focus  on  the  issues 
at  hand  without  being  overly  influenced  by  side  issues. 

Results  of  simulations  can  be  skewed  by  random  activities  in  the  solution  that  are  not 
directly  related  to  the  issues  at  hand. 

3.  Determine  the  measures  needed  to  support  the  evaluation  method. 
Consider  the  impact  on  cost,  schedule,  performance,  and  risks. 

SP  1 .5  Evaluate  Alternative  Solutions 

Evaluate  alternative  solutions  using  established  criteria  and 
methods. 

Evaluating  alternative  solutions  involves  analysis,  discussion,  and  review. 
Iterative  cycles  of  analysis  are  sometimes  necessary.  Supporting  analyses, 
experimentation,  prototyping,  piloting,  or  simulations  may  be  needed  to 
substantiate  scoring  and  conclusions. 

Often,  the  relative  importance  of  criteria  is  imprecise  and  the  total  effect  on 
a  solution  is  not  apparent  until  after  the  analysis  is  performed.  In  cases 
where  the  resulting  scores  differ  by  relatively  small  amounts,  the  best 
selection  among  alternative  solutions  may  not  be  clear.  Challenges  to 
criteria  and  assumptions  should  be  encouraged. 

Example  Work  Products 

1 .  Evaluation  results 

Subpractices 

1 .  Evaluate  proposed  alternative  solutions  using  the  established 
evaluation  criteria  and  selected  methods. 

2.  Evaluate  assumptions  related  to  the  evaluation  criteria  and  the 
evidence  that  supports  the  assumptions. 

3.  Evaluate  whether  uncertainty  in  the  values  for  alternative  solutions 
affects  the  evaluation  and  address  these  uncertainties  as  appropriate. 

For  instance,  if  the  score  varies  between  two  values,  is  the  difference  significant 
enough  to  make  a  difference  in  the  final  solution  set?  Does  the  variation  in  score 
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represent  a  high-impact  risk?  To  address  these  concerns,  simulations  may  be  run, 
further  studies  may  be  performed,  or  evaluation  criteria  may  be  modified,  among  other 
things. 

4.  Perform  simulations,  modeling,  prototypes,  and  pilots  as  necessary  to 
exercise  the  evaluation  criteria,  methods,  and  alternative  solutions. 

Untested  criteria,  their  relative  importance,  and  supporting  data  or  functions  can  cause 
the  validity  of  solutions  to  be  questioned.  Criteria  and  their  relative  priorities  and  scales 
can  be  tested  with  trial  runs  against  a  set  of  alternatives.  These  trial  runs  of  a  select 
set  of  criteria  allow  for  the  evaluation  of  the  cumulative  impact  of  criteria  on  a  solution. 
If  trials  reveal  problems,  different  criteria  or  alternatives  might  be  considered  to  avoid 
biases. 

5.  Consider  new  alternative  solutions,  criteria,  or  methods  if  proposed 
alternatives  do  not  test  well;  repeat  evaluations  until  alternatives  do 
test  well. 

6.  Document  the  results  of  the  evaluation. 

Document  the  rationale  for  the  addition  of  new  alternatives  or  methods  and  changes  to 
criteria,  as  well  as  the  results  of  interim  evaluations. 

SP  1.6  Select  Solutions 

Select  solutions  from  alternatives  based  on  evaluation  criteria. 

Selecting  solutions  involves  weighing  results  from  the  evaluation  of 
alternatives.  Risks  associated  with  the  implementation  of  solutions  should 
be  assessed. 

Example  Work  Products 

1 .  Recommended  solutions  to  address  significant  issues 
Subpractices 

1 .  Assess  the  risks  associated  with  implementing  the  recommended 
solution. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  anaiyzing  risks  and  mitigating  risks. 

Decisions  must  often  be  made  with  incomplete  information.  There  can  be  substantial 
risk  associated  with  the  decision  because  of  having  incomplete  information. 

When  decisions  must  be  made  according  to  a  specific  schedule,  time  and  resources 
may  not  be  available  forgathering  complete  information.  Consequently,  risky  decisions 
made  with  incomplete  information  can  require  re-analysis  later.  Identified  risks  should 
be  monitored. 

2.  Document  and  communicate  to  relevant  stakeholders  the  results  and 
rationale  for  the  recommended  solution. 

It  is  important  to  record  both  why  a  solution  is  selected  and  why  another  solution  was 
rejected. 
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INTEGRATED  PROJECT  MANAGEMENT 

A  Project  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Integrated  Project  Management  (IPM)  is  to  establish  and 
manage  the  project  and  the  involvement  of  relevant  stakeholders  according 
to  an  integrated  and  defined  process  that  is  tailored  from  the  organization’s 
set  of  standard  processes. 


Introductory  Notes 


Integrated  Project  Management  involves  the  following  activities: 

•  Establishing  the  project’s  defined  process  at  project  startup  by  tailoring 
the  organization’s  set  of  standard  processes 

•  Managing  the  project  using  the  project’s  defined  process 

•  Establishing  the  work  environment  for  the  project  based  on  the 
organization’s  work  environment  standards 

•  Establishing  teams  that  are  tasked  to  accomplish  project  objectives 

•  Using  and  contributing  to  organizational  process  assets 

•  Enabling  relevant  stakeholders’  concerns  to  be  identified,  considered, 
and,  when  appropriate,  addressed  during  the  project 

•  Ensuring  that  relevant  stakeholders  (1 )  perform  their  tasks  in  a 
coordinated  and  timely  manner;  (2)  address  project  requirements, 
plans,  objectives,  problems,  and  risks;  (3)  fulfill  their  commitments;  and 
(4)  identify,  track,  and  resolve  coordination  issues 

The  integrated  and  defined  process  that  is  tailored  from  the  organization’s 
set  of  standard  processes  is  called  the  project’s  defined  process.  (See  the 
definition  of  “project”  in  the  glossary.) 

Managing  the  project’s  effort,  cost,  schedule,  staffing,  risks,  and  other 
factors  is  tied  to  the  tasks  of  the  project’s  defined  process.  The 
implementation  and  management  of  the  project’s  defined  process  are 
typically  described  in  the  project  plan.  Certain  activities  may  be  covered  in 
other  plans  that  affect  the  project,  such  as  the  quality  assurance  plan,  risk 
management  strategy,  and  the  configuration  management  plan. 

Since  the  defined  process  for  each  project  is  tailored  from  the 
organization’s  set  of  standard  processes,  variability  among  projects  is 
typically  reduced  and  projects  can  easily  share  process  assets,  data,  and 
lessons  learned. 
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This  process  area  also  addresses  the  coordination  of  all  activities  associated  with  the  project 
such  as  the  following: 

•  Development  activities  (e.g.,  requirements  development,  design,  verification) 

•  Service  activities  (e.g.,  delivery,  help  desk,  operations,  customer  contact) 

•  Acquisition  activities  (e.g.,  solicitation,  agreement  monitoring,  transition  to  operations) 

•  Support  activities  (e.g.,  configuration  management,  documentation,  marketing,  training) 


The  working  interfaces  and  interactions  among  relevant  stakeholders 
internal  and  external  to  the  project  are  planned  and  managed  to  ensure  the 
quality  and  integrity  of  the  overall  endeavor.  Relevant  stakeholders 
participate  as  appropriate  in  defining  the  project’s  defined  process  and  the 
project  plan.  Reviews  and  exchanges  are  regularly  conducted  with  relevant 
stakeholders  to  ensure  that  coordination  issues  receive  appropriate 
attention  and  everyone  involved  with  the  project  is  appropriately  aware  of 
status,  plans,  and  activities.  (See  the  definition  of  “relevant  stakeholder”  in 
the  glossary.)  In  defining  the  project’s  defined  process,  formal  interfaces  are 
created  as  necessary  to  ensure  that  appropriate  coordination  and 
collaboration  occurs. 

This  process  area  applies  in  any  organizational  structure,  including  projects 
that  are  structured  as  line  organizations,  matrix  organizations,  or  teams. 

The  terminology  should  be  appropriately  interpreted  for  the  organizational 
structure  in  place. 

Related  Process  Areas 


Refer  to  the  Verification  process  area  for  more  information  about  performing 
peer  reviews. 

Refer  to  the  Measurement  and  Anaiysis  process  area  for  more  information 
about  aiigning  measurement  and  anaiysis  activities  and  providing 
measurement  resuits. 

Refer  to  the  Organizationai  Process  Definition  process  area  for  more 
information  about  estabiishing  and  maintaining  a  usabie  set  of 
organizationai  process  assets,  work  environment  standards,  and  ruies  and 
guideiines  for  teams. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  monitoring  the  project  against  the  pian. 

Refer  to  the  Project  Pianning  process  area  for  more  information  about 
deveioping  a  project  pian. 
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Specific  Goai  and  Practice  Summary 

SG  1  Use  the  Project’s  Defined  Process 

SP  1 .1  Establish  the  Project’s  Defined  Process 

SP  1 .2  Use  Organizational  Process  Assets  for  Planning  Project  Activities 
SP  1 .3  Establish  the  Project’s  Work  Environment 

SP  1 .4  Integrate  Plans 

SP  1 .5  Manage  the  Project  Using  Integrated  Plans 
SP  1 .6  Establish  T  earns 

SP  1 .7  Contribute  to  Organizational  Process  Assets 
SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders 
SP  2.1  Manage  Stakeholder  Involvement 

SP  2.2  Manage  Dependencies 

SP  2.3  Resolve  Coordination  Issues 

Specific  Practices  by  Goai 


SG  1  Use  the  Project’s  Defined  Process 

The  project  is  conducted  using  a  defined  process  taiiored  from  the 
organization’s  set  of  standard  processes. 

The  project’s  defined  process  includes  those  processes  from  the 
organization’s  set  of  standard  processes  that  address  all  processes 
necessary  to  acquire,  develop,  maintain,  or  deliver  the  product. 

The  product  related  lifecycle  processes,  such  as  manufacturing  and  support 
processes,  are  developed  concurrently  with  the  product. 

SP  1.1  Establish  the  Project’s  Defined  Process 

Estabiish  and  maintain  the  project’s  defined  process  from  project 
startup  through  the  fife  of  the  project. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets  and 
establishing  the  organization’s  measurement  repository. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  deploying  organizational  process  assets  and  deploying 
standard  processes. 

The  project’s  defined  process  consists  of  defined  processes  that  form  an 
integrated,  coherent  lifecycle  for  the  project. 

The  project’s  defined  process  should  satisfy  the  project’s  contractual 
requirements,  operational  needs,  opportunities,  and  constraints.  It  is 
designed  to  provide  a  best  fit  for  project  needs. 

A  project’s  defined  process  is  based  on  the  following  factors: 

•  Stakeholder  requirements 

•  Commitments 

•  Organizational  process  needs  and  objectives 

•  The  organization’s  set  of  standard  processes  and  tailoring  guidelines 
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•  The  operational  environment 

•  The  business  environment 

Establishing  the  project’s  defined  process  at  project  startup  helps  to  ensure 
that  project  staff  and  relevant  stakeholders  implement  a  set  of  activities 
needed  to  efficiently  establish  an  initial  set  of  requirements  and  plans  for 
the  project.  As  the  project  progresses,  the  description  of  the  project’s 
defined  process  is  elaborated  and  revised  to  better  meet  project 
requirements  and  the  organization’s  process  needs  and  objectives.  Also,  as 
the  organization’s  set  of  standard  processes  changes,  the  project’s  defined 
process  may  need  to  be  revised. 

Example  Work  Products 

1 .  The  project’s  defined  process 

Subpractices 

1 .  Select  a  lifecycle  model  from  the  ones  available  in  organizational 
process  assets. 

^ - 

I  Examples  of  project  characteristics  that  could  affect  the  selection  of  lifecycle  models 

i  Include  the  following: 

I  •  Size  or  complexity  of  the  project 
I  •  Project  strategy 

;  •  Experience  and  familiarity  of  staff  with  Implementing  the  process 
;  •  Constraints  such  as  cycle  time  and  acceptable  defect  levels 
I  •  Availability  of  customers  to  answer  questions  and  provide  feedback  on  Increments 
I  •  Clarity  of  requirements 
I  •  Customer  expectations 


2.  Select  standard  processes  from  the  organization’s  set  of  standard 
processes  that  best  fit  the  needs  of  the  project. 

3.  Tailor  the  organization’s  set  of  standard  processes  and  other 
organizational  process  assets  according  to  tailoring  guidelines  to 
produce  the  project’s  defined  process. 

Sometimes  the  available  lifecycle  models  and  standard  processes  are  inadequate  to 
meet  project  needs.  In  such  circumstances,  the  project  should  seek  approval  to 
deviate  from  what  is  required  by  the  organization.  Waivers  are  provided  for  this 
purpose. 

Tailoring  can  include  adapting  the  organization’s  common  measures  and  specifying 
additional  measures  to  meet  the  information  needs  of  the  project. 

4.  Use  other  artifacts  from  the  organization’s  process  asset  library  as 
appropriate. 
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I  other  artifacts  can  include  the  following: 

I  •  Lessons  learned  documents 
I  •  Templates 
I  •  Example  documents 
•  Estimating  models 


5.  Document  the  project’s  defined  process. 

The  project’s  defined  process  covers  all  of  the  activities  for  the  project  and  its 
interfaces  to  relevant  stakeholders. 

f. - - 

I  Examples  of  project  activities  include  the  following: 

I  •  Project  planning 
I  •  Project  monitoring 
I  •  Supplier  management 
j  •  Quality  assurance 
I  •  Risk  management 
I  •  Decision  analysis  and  resolution 
i  •  Requirements  development 
i  •  Requirements  management 
i  •  Configuration  management 
;  •  Product  development  and  support 
;  •  Code  review 
i  •  Solicitation 


6.  Conduct  peer  reviews  of  the  project’s  defined  process. 

Refer  to  the  Verification  process  area  for  more  information  about 
performing  peer  reviews. 

7.  Revise  the  project’s  defined  process  as  necessary. 

SP  1.2  Use  Organizational  Process  Assets  for  Planning  Project  Activities 

Use  organizational  process  assets  and  the  measurement 
repository  for  estimating  and  planning  project  activities. 

Refer  to  the  Organizationai  Process  Definition  process  area  for  more 
information  about  estabiishing  organizationai  process  assets. 

When  available,  use  results  of  previous  planning  and  execution  activities  as 
predictors  of  the  relative  scope  and  risk  of  the  effort  being  estimated. 

Example  Work  Products 

1 .  Project  estimates 

2.  Project  plans 
Subpractices 

1 .  Use  the  tasks  and  work  products  of  the  project’s  defined  process  as  a 
basis  for  estimating  and  planning  project  activities. 
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An  understanding  of  the  relationships  among  tasks  and  work  products  of  the  project’s 
defined  process,  and  of  the  roles  to  be  performed  by  relevant  stakeholders,  is  a  basis 
for  developing  a  realistic  plan. 

2.  Use  the  organization’s  measurement  repository  in  estimating  the 
project’s  planning  parameters. 

^ - 

I  This  estimate  typically  includes  the  following: 

I  •  Appropriate  historical  data  from  this  project  or  similar  projects 

j  •  Similarities  and  differences  between  the  current  project  and  those  projects  whose 

I  historical  data  will  be  used 

I  •  Validated  historical  data 

I  •  Reasoning,  assumptions,  and  rationale  used  to  select  the  historical  data 

[  •  Reasoning  of  a  broad  base  of  experienced  project  participants 


Examples  of  parameters  that  are  considered  for  similarities  and  differences  include  the 
following: 

•  Work  product  and  task  attributes 

•  Application  domain 

•  Experience  of  the  people 

•  Design  and  development  approaches 

•  Operational  environment 


Examples  of  data  contained  in  the  organization’s  measurement  repository  include  the 
following: 

•  Size  of  work  products  or  other  work  product  attributes 

•  Effort 

•  Cost 

•  Schedule 

•  Staffing 

•  Response  time 

•  Service  capacity 

•  Supplier  performance 

•  Defects 


SP  1.3  Establish  the  Project’s  Work  Environment 

Establish  and  maintain  the  project’s  work  environment  based  on 
the  organization’s  work  environment  standards. 

An  appropriate  work  environment  for  a  project  comprises  an  infrastructure 
of  facilities,  tools,  and  equipment  that  people  need  to  perform  their  jobs 
effectively  in  support  of  business  and  project  objectives.  The  work 
environment  and  its  components  are  maintained  at  a  level  of  work 
environment  performance  and  reliability  indicated  by  organizational  work 
environment  standards.  As  required,  the  project’s  work  environment  or 
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some  of  its  components  can  be  developed  internally  or  acquired  from 
external  sources. 

The  project’s  work  environment  might  encompass  environments  for  product 
integration,  verification,  and  validation  or  they  might  be  separate 
environments. 

Refer  to  the  Establish  the  Product  Integration  Environment  specific  practice 
in  the  Product  Integration  process  area  for  more  information  about 
establishing  and  maintaining  the  product  integration  environment  for  the 
project. 

Refer  to  the  Establish  the  Validation  Environment  specific  practice  in  the 
Validation  process  area  for  more  information  about  establishing  and 
maintaining  the  validation  environment  for  the  project. 

Refer  to  the  Establish  the  Verification  Environment  specific  practice  in  the 
Verification  process  area  for  more  information  about  establishing  and 
maintaining  the  verification  environment  for  the  project. 

Refer  to  the  Establish  Work  Environment  Standards  specific  practice  in  the 
Organizational  Process  Definition  process  area  for  more  information  about 
work  environment  standards. 

Example  Work  Products 

1 .  Equipment  and  tools  for  the  project 

2.  Installation,  operation,  and  maintenance  manuals  for  the  project  work 
environment 

3.  User  surveys  and  results 

4.  Use,  performance,  and  maintenance  records 

5.  Support  services  for  the  project’s  work  environment 
Subpractices 

1 .  Plan,  design,  and  install  a  work  environment  for  the  project. 

The  critical  aspects  of  the  project  work  environment  are,  like  any  other  product, 
requirements  driven.  Functionality  and  quality  attributes  of  the  work  environment  are 
explored  with  the  same  rigor  as  is  done  for  any  other  product  development  project. 

f. - - 

I  It  may  be  necessary  to  make  tradeoffs  among  quality  attributes,  costs,  and  risks.  The 
;  following  are  examples  of  each: 

i  •  Quality  attribute  considerations  can  include  timely  communication,  safety,  security,  and 
i  maintainability. 

I  •  Costs  can  include  capital  outlays,  training,  a  support  structure;  disassembly  and 
;  disposal  of  existing  environments;  and  the  operation  and  maintenance  of  the 
;  environment. 

I  •  Risks  can  include  workflow  and  project  disruptions. 
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Examples  of  equipment  and  tools  include  the  following: 

•  Office  software 

•  Decision  support  software 

•  Project  management  tools 

•  Test  and  evaluation  equipment 

•  Requirements  management  tools  and  design  tools 

•  Configuration  management  tools 

•  Evaluation  tools 

•  Integration  tools 

•  Automated  test  tools 


2.  Provide  ongoing  maintenance  and  operational  support  for  the  project’s 
work  environment. 

Maintenance  and  support  of  the  work  environment  can  be  accomplished  either  with 
capabilities  found  inside  the  organization  or  hired  from  outside  the  organization. 

;  Examples  of  maintenance  and  support  approaches  include  the  following: 

I  •  Hiring  people  to  perform  maintenance  and  support 
I  •  Training  people  to  perform  maintenance  and  support 
I  •  Contracting  maintenance  and  support 
I  •  Developing  expert  users  for  selected  tools 

3.  Maintain  the  qualification  of  components  of  the  project’s  work 
environment. 

Components  include  software,  databases,  hardware,  tools,  test  equipment,  and 
appropriate  documentation.  Qualification  of  software  includes  appropriate 
certifications.  Hardware  and  test  equipment  qualification  includes  calibration  and 
adjustment  records  and  traceability  to  calibration  standards. 

4.  Periodically  review  how  well  the  work  environment  is  meeting  project 
needs  and  supporting  collaboration,  and  take  action  as  appropriate. 

I  Examples  of  actions  that  might  be  taken  include  the  following: 

I  •  Adding  new  tools 

[  •  Acquiring  additional  networks,  equipment,  training,  and  support 


SP1.4  Integrate  Plans 

Integrate  the  project  plan  and  other  plans  that  affect  the  project  to 
describe  the  project’s  defined  process. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets  and,  in 
particular,  establishing  the  organization’s  measurement  repository. 
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Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  establishing  organizational  process  needs  and 
determining  process  improvement  opportunities. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
developing  a  project  plan. 

This  specific  practice  extends  the  specific  practices  for  establishing  and 
maintaining  a  project  plan  to  address  additional  planning  activities  such  as 
incorporating  the  project’s  defined  process,  coordinating  with  relevant 
stakeholders,  using  organizational  process  assets,  incorporating  plans  for 
peer  reviews,  and  establishing  objective  entry  and  exit  criteria  for  tasks. 

The  development  of  the  project  plan  should  account  for  current  and 
projected  needs,  objectives,  and  requirements  of  the  organization, 
customer,  suppliers,  and  end  users  as  appropriate. 

Example  Work  Products 

1 .  Integrated  plans 

Subpractices 

1 .  Integrate  other  plans  that  affect  the  project  with  the  project  plan. 

f. - 

I  Other  plans  that  affect  the  project  plan  can  include  the  following: 

I  •  Quality  assurance  plans 
I  •  Risk  management  strategy 
I  •  Verification  and  validation  plans 
I  •  Transition  to  operations  and  support  plans 
j  •  Configuration  management  plans 
I  •  Documentation  plans 
I  •  Staff  training  plans 
[  •  Facilities  and  logistics  plans 

2.  Incorporate  into  the  project  plan  the  definitions  of  measures  and 
measurement  activities  for  managing  the  project. 

f. - 

I  Examples  of  measures  that  would  be  incorporated  include  the  following: 

I  •  Organization's  common  set  of  measures 
I  •  Additional  project  specific  measures 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  developing  and  sustaining  a  measurement  capability 
used  to  support  management  information  needs. 

3.  Identify  and  analyze  product  and  project  interface  risks. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  analyzing  risks. 
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Examples  of  product  and  project  interface  risks  include  the  following: 

•  Incomplete  interface  descriptions 

•  Unavailability  of  tools,  suppliers,  or  test  equipment 

•  Unavailability  of  COTS  components 

•  Inadequate  or  ineffective  team  interfaces 


4.  Schedule  tasks  in  a  sequence  that  accounts  for  critical  development 
and  delivery  factors  and  project  risks. 

;  Examples  of  factors  considered  in  scheduling  include  the  following: 

I  •  Size  and  complexity  of  tasks 
I  •  Needs  of  the  customer  and  end  users 
I  •  Availability  of  critical  resources 
:  •  Availability  of  key  staff 
•  Integration  and  test  issues 

5.  Incorporate  plans  for  performing  peer  reviews  on  work  products  of  the 
project’s  defined  process. 

Refer  to  the  Verification  process  area  for  more  information  about 
performing  peer  reviews. 

6.  Incorporate  the  training  needed  to  perform  the  project’s  defined 
process  in  the  project’s  training  plans. 

This  task  typically  includes  negotiating  with  the  organizational  training  group  on  the 
support  they  will  provide. 

7.  Establish  objective  entry  and  exit  criteria  to  authorize  the  initiation  and 
completion  of  tasks  described  in  the  work  breakdown  structure  (WBS). 

Refer  to  the  Project  Pianning  process  area  for  more  information  about 
estimating  the  scope  of  the  project. 

8.  Ensure  that  the  project  plan  is  appropriately  compatible  with  the  plans 
of  relevant  stakeholders. 

Typically  the  plan  and  changes  to  the  plan  will  be  reviewed  for  compatibility. 

9.  Identify  how  conflicts  will  be  resolved  that  arise  among  relevant 
stakeholders. 

SP  1.5  Manage  the  Project  Using  Integrated  Plans 

Manage  the  project  using  the  project  plan,  other  plans  that  affect 
the  project,  and  the  project’s  defined  process. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  estabiishing  organizationai  process  assets. 

Refer  to  the  Organizationai  Process  Focus  process  area  for  more 
information  about  estabiishing  organizationai  process  needs,  deploying 
organizational  process  assets,  and  deploying  standard  processes. 


166 


Integrated  Project  Management  (IPM) 


CMMI  for  Development,  Version  1.3 


Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  providing  an  understanding  of  the  project’s  progress  so 
that  appropriate  corrective  actions  can  be  taken  when  the  project’s 
performance  deviates  significantiy  from  the  pian. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  anaiyzing  risks  and  mitigating  risks. 

Example  Work  Products 

1 .  Work  products  created  by  performing  the  project’s  defined  process 

2.  Collected  measures  (i.e.,  actuals)  and  status  records  or  reports 

3.  Revised  requirements,  plans,  and  commitments 

4.  Integrated  plans 
Subpractices 

1 .  Implement  the  project’s  defined  process  using  the  organization’s 
process  asset  library. 

i  This  task  typically  Includes  the  following  activities: 

;  •  Incorporating  artifacts  from  the  organization's  process  asset  library  Into  the  project  as 
i  appropriate 

;  •  Using  lessons  learned  from  the  organization's  process  asset  library  to  manage  the 
i  project 


2.  Monitor  and  control  the  project’s  activities  and  work  products  using  the 
project’s  defined  process,  project  plan,  and  other  plans  that  affect  the 
project. 

;  This  task  typically  Includes  the  following  activities: 

I  •  Using  the  defined  entry  and  exit  criteria  to  authorize  the  Initiation  and  determine  the 
I  completion  of  tasks 

I  •  Monitoring  activities  that  could  significantly  affect  actual  values  of  the  project's  planning 
I  parameters 

I  •  Tracking  project  planning  parameters  using  measurable  thresholds  that  will  trigger 
I  Investigation  and  appropriate  actions 

I  •  Monitoring  product  and  project  Interface  risks 

j  •  Managing  external  and  Internal  commitments  based  on  plans  for  tasks  and  work 
I  products  of  the  project's  defined  process 


An  understanding  of  the  relationships  among  tasks  and  work  products  of  the  project’s 
defined  process  and  of  the  roles  to  be  performed  by  relevant  stakeholders,  along  with 
well-defined  control  mechanisms  (e.g.,  peer  reviews),  achieves  better  visibility  Into 
project  performance  and  better  control  of  the  project. 

3.  Obtain  and  analyze  selected  measurements  to  manage  the  project  and 
support  organization  needs. 

Refer  to  the  Measurement  and  Anaiysis  process  area  for  more 
information  about  obtaining  measurement  data  and  anaiyzing 
measurement  data. 
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4.  Periodically  review  and  align  the  project’s  performance  with  current 
and  anticipated  needs,  objectives,  and  requirements  of  the 
organization,  customer,  and  end  users  as  appropriate. 

This  review  includes  alignment  with  organizational  process  needs  and  objectives. 

i  Examples  of  actions  that  achieve  alignment  include  the  following: 

;  •  Changing  the  schedule  with  appropriate  adjustments  to  other  planning  parameters  and 
i  project  risks 

;  •  Changing  requirements  or  commitments  in  response  to  a  change  in  market 
i  opportunities  or  customer  and  end-user  needs 

i  •  Terminating  the  project,  iteration,  or  release 

5.  Address  causes  of  selected  issues  that  can  affect  project  objectives. 

Issues  that  require  corrective  action  are  determined  and  analyzed  as  in  the  Analyze 
Issues  and  Take  Corrective  Actions  specific  practices  of  the  Project  Monitoring  and 
Control  process  area.  As  appropriate,  the  project  may  periodically  review  issues 
previously  encountered  on  other  projects  or  in  earlier  phases  of  the  project,  and 
conduct  causal  analysis  of  selected  issues  to  determine  how  to  prevent  recurrence  for 
issues  which  can  significantly  affect  project  objectives.  Project  process  changes 
implemented  as  a  result  of  causal  analysis  activities  should  be  evaluated  for 
effectiveness  to  ensure  that  the  process  change  has  prevented  recurrence  and 
improved  performance. 

SP  1.6  Establish  Teams 

Establish  and  maintain  teams. 

The  project  is  managed  using  teams  that  reflect  the  organizational  rules 
and  guidelines  for  team  structuring,  formation,  and  operation.  (See  the 
definition  of  “team”  in  the  glossary.) 

The  project’s  shared  vision  is  established  prior  to  establishing  the  team 
structure,  which  can  be  based  on  the  WBS.  For  small  organizations,  the 
whole  organization  and  relevant  external  stakeholders  can  be  treated  as  a 
team. 

Refer  to  the  Establish  Rules  and  Guidelines  for  Teams  specific  practice  in 
the  Organizational  Process  Definition  process  area  for  more  information 
about  establishing  and  maintaining  organizational  rules  and  guidelines  for 
the  structure,  formation,  and  operation  of  teams. 

One  of  the  best  ways  to  ensure  coordination  and  collaboration  with  relevant 
stakeholders  is  to  include  them  on  the  team. 

In  a  customer  environment  that  requires  coordination  among  multiple 
product  or  service  development  organizations,  it  is  important  to  establish  a 
team  with  representation  from  all  parties  that  affect  overall  success.  Such 
representation  helps  to  ensure  effective  collaboration  across  these 
organizations,  including  the  timely  resolution  of  coordination  issues. 

Example  Work  Products 

1 .  Documented  shared  vision 
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2.  List  of  members  assigned  to  each  team 

3.  Team  charters 

4.  Periodic  team  status  reports 
Subpractices 

1 .  Establish  and  maintain  the  project’s  shared  vision. 

When  creating  a  shared  vision,  it  is  critical  to  understand  the  interfaces  between  the 
project  and  stakeholders  external  to  the  project.  The  vision  should  be  shared  among 
relevant  stakeholders  to  obtain  their  agreement  and  commitment. 

2.  Establish  and  maintain  the  team  structure. 

The  project  WBS,  cost,  schedule,  project  risks,  resources,  interfaces,  the  project’s 
defined  process,  and  organizational  guidelines  are  evaluated  to  establish  an 
appropriate  team  structure,  including  team  responsibilities,  authorities,  and 
interrelationships. 

3.  Establish  and  maintain  each  team. 

Establishing  and  maintaining  teams  encompasses  choosing  team  leaders  and  team 
members  and  establishing  team  charters  for  each  team.  It  also  involves  providing 
resources  required  to  accomplish  tasks  assigned  to  the  team. 

4.  Periodically  evaluate  the  team  structure  and  composition. 

Teams  should  be  monitored  to  detect  misalignment  of  work  across  different  teams, 
mismanaged  interfaces,  and  mismatches  of  tasks  to  team  members.  Take  corrective 
action  when  team  or  project  performance  does  not  meet  expectations. 

SP  1 .7  Contribute  to  Organizational  Process  Assets 

Contribute  process  related  experiences  to  organizational  process 
assets. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets,  establishing 
the  organization’s  measurement  repository,  and  establishing  the 
organization’s  process  asset  library. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  incorporating  experiences  into  organizational  process 
assets. 

This  specific  practice  addresses  contributing  information  from  processes  in 
the  project’s  defined  process  to  organizational  process  assets. 

Example  Work  Products 

1 .  Proposed  improvements  to  organizational  process  assets 

2.  Actual  process  and  product  measures  collected  from  the  project 

3.  Documentation  (e.g.,  exemplary  process  descriptions,  plans,  training 
modules,  checklists,  lessons  learned) 

4.  Process  artifacts  associated  with  tailoring  and  implementing  the 
organization’s  set  of  standard  processes  on  the  project 
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Subpractices 

1 .  Propose  improvements  to  the  organizational  process  assets. 

2.  Store  process  and  product  measures  in  the  organization’s 
measurement  repository. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  obtaining  measurement  data. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  planning  parameters. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  data  management. 

i  These  process  and  product  measures  typically  include  the  following: 

i  •  Planning  data 
i  •  Replanning  data 

;  Examples  of  data  recorded  by  the  project  include  the  following: 

i  •  Task  descriptions 
I  •  Assumptions 
I  •  Estimates 
;  •  Revised  estimates 

;  •  Definitions  of  recorded  data  and  measures 
I  •  Measures 

I  •  Context  information  that  relates  the  measures  to  the  activities  performed  and  work 
I  products  produced 

I  •  Associated  information  needed  to  reconstruct  the  estimates,  assess  their 
I  reasonableness,  and  derive  estimates  for  new  work 

3.  Submit  documentation  for  possible  inclusion  in  the  organization’s 
process  asset  library. 

;  Examples  of  documentation  include  the  following: 

I  •  Exemplary  process  descriptions 
I  •  Training  modules 
;  •  Exemplary  plans 
;  •  Checklists  and  templates 
I  •  Project  repository  shells 
I  •  Tool  configurations 

4.  Document  lessons  learned  from  the  project  for  inclusion  in  the 
organization’s  process  asset  library. 

5.  Provide  process  artifacts  associated  with  tailoring  and  implementing 
the  organization’s  set  of  standard  processes  in  support  of  the 
organization’s  process  monitoring  activities. 
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Refer  to  the  Monitor  the  Implementation  specific  practice  in  the 
Organizational  Process  Focus  process  area  for  more  information  about 
the  organization’s  activities  to  understand  the  extent  of  deployment  of 
standard  processes  on  new  and  existing  projects. 

SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders 

Coordination  and  coiiaboration  between  the  project  and  reievant  stakehoiders 
are  conducted. 


SP  2.1  Manage  Stakeholder  Involvement 

Manage  the  invoivement  of  reievant  stakehoiders  in  the  project. 

Stakeholder  involvement  is  managed  according  to  the  project’s  integrated 
plan  and  defined  process. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  stakeholder  involvement  and  obtaining  plan  commitment. 

Example  Work  Products 

1 .  Agendas  and  schedules  for  collaborative  activities 

2.  Recommendations  for  resolving  relevant  stakeholder  issues 

3.  Documented  issues  (e.g.,  issues  with  stakeholder  requirements, 
product  and  product  component  requirements,  product  architecture, 
product  design) 

Subpractices 

1 .  Coordinate  with  relevant  stakeholders  who  should  participate  in  project 
activities. 

The  relevant  stakeholders  should  already  be  identified  in  the  project  plan. 

2.  Ensure  work  products  that  are  produced  to  satisfy  commitments  meet 
the  requirements  of  the  recipients. 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  selected  work  products. 

The  work  products  produced  to  satisfy  commitments  can  be  services. 

This  task  typically  includes  the  following: 

•  Reviewing,  demonstrating,  or  testing,  as  appropriate,  each  work  product  produced  by 
relevant  stakeholders 

•  Reviewing,  demonstrating,  or  testing,  as  appropriate,  each  work  product  produced  by 
the  project  for  other  projects  with  representatives  of  the  projects  receiving  the  work 
product 

•  Resolving  issues  related  to  the  acceptance  of  the  work  products 

3.  Develop  recommendations  and  coordinate  actions  to  resolve 
misunderstandings  and  problems  with  requirements. 
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SP  2.2  Manage  Dependencies 

Participate  with  reievant  stakehoiders  to  identify,  negotiate,  and 
track  criticai  dependencies. 


Example  Work  Products 

1 .  Defects,  issues,  and  action  items  resulting  from  reviews  with  relevant 
stakeholders 

2.  Critical  dependencies 

3.  Commitments  to  address  critical  dependencies 

4.  Status  of  critical  dependencies 

Subpractices 

1 .  Conduct  reviews  with  relevant  stakeholders. 

2.  Identify  each  critical  dependency. 

3.  Establish  need  dates  and  plan  dates  for  each  critical  dependency 
based  on  the  project  schedule. 

4.  Review  and  get  agreement  on  commitments  to  address  each  critical 
dependency  with  those  who  are  responsible  for  providing  or  receiving 
the  work  product. 

5.  Document  critical  dependencies  and  commitments. 

:  Documentation  of  commitments  typically  Includes  the  following: 

i  •  Describing  the  commitment 

i  •  Identifying  who  made  the  commitment 

i  •  Identifying  who  Is  responsible  for  satisfying  the  commitment 

i  •  Specifying  when  the  commitment  will  be  satisfied 

;  •  Specitying  the  criteria  for  determining  if  the  commitment  has  been  satisfied 

6.  Track  the  critical  dependencies  and  commitments  and  take  corrective 
action  as  appropriate. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  monitoring  commitments. 

;  Tracking  critical  dependencies  typically  includes  the  following: 

;  •  Evaluating  the  effects  of  late  and  early  completion  for  impacts  on  future  activities  and 
I  milestones 

;  •  Resolving  actual  and  potential  problems  with  responsible  parties  whenever  possible 

I  •  Escalating  to  the  appropriate  party  the  actual  and  potential  problems  not  resolvable  by 
I  the  responsible  individual  or  group 
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SP  2.3  Resolve  Coordination  Issues 

Resolve  issues  with  relevant  stakeholders. 

;  Examples  of  coordination  issues  include  the  following: 
i  •  Product  and  product  component  requirements  and  design  defects 
;  •  Late  critical  dependencies  and  commitments 
I  •  Product  level  problems 
I  •  Unavailability  of  critical  resources  or  staff 


Example  Work  Products 

1 .  Relevant  stakeholder  coordination  issues 

2.  Status  of  relevant  stakeholder  coordination  issues 
Subpractices 

1 .  Identify  and  document  issues. 

2.  Communicate  issues  to  relevant  stakeholders. 

3.  Resolve  issues  with  relevant  stakeholders. 

4.  Escalate  to  appropriate  managers  the  issues  not  resolvable  with 
relevant  stakeholders. 

5.  Track  issues  to  closure. 

6.  Communicate  with  relevant  stakeholders  on  the  status  and  resolution 
of  issues. 
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MEASUREMENT  AND  ANALYSIS 

A  Support  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Measurement  and  Analysis  (MA)  is  to  develop  and  sustain 
a  measurement  capability  used  to  support  management  information  needs. 


Introductory  Notes 


The  Measurement  and  Analysis  process  area  involves  the  following 
activities: 

•  Specifying  objectives  of  measurement  and  analysis  so  that  they  are 
aligned  with  identified  information  needs  and  project,  organizational,  or 
business  objectives 

•  Specifying  measures,  analysis  techniques,  and  mechanisms  for  data 
collection,  data  storage,  reporting,  and  feedback 

•  Implementing  the  analysis  techniques  and  mechanisms  for  data 
collection,  data  reporting,  and  feedback 

•  Providing  objective  results  that  can  be  used  in  making  informed 
decisions  and  taking  appropriate  corrective  action 

The  integration  of  measurement  and  analysis  activities  into  the  processes 
of  the  project  supports  the  following: 

•  Objective  planning  and  estimating 

•  Tracking  actual  progress  and  performance  against  established  plans 
and  objectives 

•  Identifying  and  resolving  process  related  issues 

•  Providing  a  basis  for  incorporating  measurement  into  additional 
processes  in  the  future 

The  staff  required  to  implement  a  measurement  capability  may  or  may  not 
be  employed  in  a  separate  organization-wide  program.  Measurement 
capability  may  be  integrated  into  individual  projects  or  other  organizational 
functions  (e.g.,  quality  assurance). 

The  initial  focus  for  measurement  activities  is  at  the  project  level.  However, 
a  measurement  capability  can  prove  useful  for  addressing  organization- 
and  enterprise-wide  information  needs.  To  support  this  capability, 
measurement  activities  should  support  information  needs  at  multiple  levels, 
including  the  business,  organizational  unit,  and  project  to  minimize  re-work 
as  the  organization  matures. 

Projects  can  store  project  specific  data  and  results  in  a  project  specific 
repository,  but  when  data  are  to  be  used  widely  or  are  to  be  analyzed  in 
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support  of  determining  data  trends  or  benchmarks,  data  may  reside  in  the 
organization’s  measurement  repository. 

Measurement  and  analysis  of  product  components  provided  by  suppliers  is 
essential  for  effective  management  of  the  quality  and  costs  of  the  project.  It 
is  possible,  with  careful  management  of  supplier  agreements,  to  provide 
insight  into  data  that  support  supplier  performance  analysis. 

Measurement  objectives  are  derived  from  information  needs  that  come  from 
project,  organizational,  or  business  objectives.  In  this  process  area,  when 
the  term  “objectives”  is  used  without  the  “measurement”  qualifier,  it 
indicates  either  project,  organizational,  or  business  objectives. 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more  information 
about  eliciting,  analyzing,  and  establishing  customer,  product,  and  product 
component  requirements. 

Refer  to  the  Configuration  Management  process  area  for  more  information 
about  establishing  and  maintaining  the  integrity  of  work  products  using 
configuration  identification,  configuration  control,  configuration  status 
accounting,  and  configuration  audits. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  the  organization’s  measurement  repository. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  planning  parameters. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  estimates. 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  quantitatively  managing  the  project. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  maintaining  bidirectional  traceability  of  requirements. 

Specific  Goal  and  Practice  Summary 

SG  1  Align  Measurement  and  Analysis  Activities 
SP  1 .1  Estabiish  Measurement  Objectives 

SP  1 .2  Specify  Measures 

SP  1 .3  Specify  Data  Coilection  and  Storage  Procedures 

SP  1 .4  Specify  Anaiysis  Procedures 

SG  2  Provide  Measurement  Results 

SP  2.1  Obtain  Measurement  Data 
SP  2.2  Analyze  Measurement  Data 

SP  2.3  Store  Data  and  Results 

SP  2.4  Communioate  Results 
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Specific  Practices  by  Goai 


SG  1  Align  Measurement  and  Analysis  Activities 

Measurement  objectives  and  activities  are  aiigned  with  identified  information 
needs  and  objectives. 

The  specific  practices  under  this  specific  goal  can  be  addressed 
concurrently  or  in  any  order. 

When  establishing  measurement  objectives,  experts  often  think  ahead 
about  necessary  criteria  for  specifying  measures  and  analysis  procedures. 
They  also  think  concurrently  about  the  constraints  imposed  by  data 
collection  and  storage  procedures. 

Often  it  is  important  to  specify  the  essential  analyses  to  be  conducted 
before  attending  to  details  of  measurement  specification,  data  collection,  or 
storage. 

SP  1.1  Establish  Measurement  Objectives 

Estabiish  and  maintain  measurement  objectives  derived  from 
identified  information  needs  and  objectives. 

Measurement  objectives  document  the  purposes  for  which  measurement 
and  analysis  are  done  and  specify  the  kinds  of  actions  that  can  be  taken 
based  on  results  of  data  analyses.  Measurement  objectives  can  also 
identify  the  change  in  behavior  desired  as  a  result  of  implementing  a 
measurement  and  analysis  activity. 

Measurement  objectives  may  be  constrained  by  existing  processes, 
available  resources,  or  other  measurement  considerations.  Judgments  may 
need  to  be  made  about  whether  the  value  of  the  result  is  commensurate 
with  resources  devoted  to  doing  the  work. 

Modifications  to  identified  information  needs  and  objectives  can,  in  turn,  be 
indicated  as  a  consequence  of  the  process  and  results  of  measurement  and 
analysis. 

f - - - - - - - 

I  Sources  of  information  needs  and  objectives  can  include  the  following: 

I  •  Project  plans 
;  •  Project  performance  monitoring 

i  •  Interviews  with  managers  and  others  who  have  information  needs 
;  •  Established  management  objectives 
i  •  Strategic  plans 
:  •  Business  plans 

I  •  Formal  requirements  or  contractual  obligations 
;  •  Recurring  or  other  troublesome  management  or  technical  problems 
i  •  Experiences  of  other  projects  or  organizational  entities 
;  •  External  industry  benchmarks 
:  •  Process  improvement  plans 
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Example  measurement  objectives  include  the  following: 

•  Provide  insight  into  schedule  fluctuations  and  progress 

•  Provide  insight  into  actual  size  compared  to  plan 

•  Identify  unplanned  growth 

•  Evaluate  the  effectiveness  of  defect  detection  throughout  the  product  development 
lifecycle 

•  Determine  the  cost  of  correcting  defects 

•  Provide  insight  into  actual  costs  compared  to  plan 

•  Evaluate  supplier  progress  against  the  plan 

•  Evaluate  the  effectiveness  of  mitigating  information  system  vulnerabilities 


Refer  to  the  Requirements  Development  process  area  for  more  information 
about  eliciting,  analyzing,  and  establishing  customer,  product,  and  product 
component  requirements. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  planning  parameters. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  estimates. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  maintaining  bidirectional  traceability  of  requirements. 

Example  Work  Products 

1 .  Measurement  objectives 

Subpractices 

1 .  Document  information  needs  and  objectives. 

2.  Prioritize  information  needs  and  objectives. 

It  can  be  neither  possible  nor  desirable  to  subject  all  initially  identified  information 
needs  to  measurement  and  analysis.  Priorities  may  also  need  to  be  set  within  the 
limits  of  available  resources. 

3.  Document,  review,  and  update  measurement  objectives. 

Carefully  consider  the  purposes  and  intended  uses  of  measurement  and  analysis. 

The  measurement  objectives  are  documented,  reviewed  by  management  and  other 
relevant  stakeholders,  and  updated  as  necessary.  Doing  so  enables  traceability  to 
subsequent  measurement  and  analysis  activities,  and  helps  to  ensure  that  analyses 
will  properly  address  identified  information  needs  and  objectives. 

It  is  important  that  users  of  measurement  and  analysis  results  be  involved  in  setting 
measurement  objectives  and  deciding  on  plans  of  action.  It  may  also  be  appropriate  to 
involve  those  who  provide  the  measurement  data. 

4.  Provide  feedback  for  refining  and  clarifying  information  needs  and 
objectives  as  necessary. 
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Identified  information  needs  and  objectives  can  be  refined  and  clarified  as  a  result  of 
setting  measurement  objectives.  Initial  descriptions  of  information  needs  may  be 
ambiguous.  Conflicts  can  arise  between  existing  needs  and  objectives.  Precise  targets 
on  an  already  existing  measure  may  be  unrealistic. 

5.  Maintain  traceability  of  measurement  objectives  to  identified 
information  needs  and  objectives. 

There  should  always  be  a  good  answer  to  the  question,  ‘‘Why  are  we  measuring  this?” 

Of  course,  measurement  objectives  can  also  change  to  reflect  evolving  information 
needs  and  objectives. 

SP  1.2  Specify  Measures 

Specify  measures  to  address  measurement  objectives. 

Measurement  objectives  are  refined  into  precise,  quantifiable  measures. 

Measurement  of  project  and  organizational  work  can  typically  be  traced  to 
one  or  more  measurement  information  categories.  These  categories  include 
the  following:  schedule  and  progress,  effort  and  cost,  size  and  stability,  and 
quality. 

Measures  can  be  either  base  or  derived.  Data  for  base  measures  are 
obtained  by  direct  measurement.  Data  for  derived  measures  come  from 
other  data,  typically  by  combining  two  or  more  base  measures. 

;  Examples  of  commonly  used  base  measures  include  the  following: 
i  •  Estimates  and  actual  measures  of  work  product  size  (e.g.,  number  of  pages) 

;  •  Estimates  and  actual  measures  of  effort  and  cost  (e.g.,  number  of  person  hours) 

i  •  Quality  measures  (e.g.,  number  of  defects  by  severity) 

:  •  Information  security  measures  (e.g.,  number  of  system  vulnerabilities  identified) 

I  •  Customer  satisfaction  survey  scores 


I  Examples  of  commonly  used  derived  measures  include  the  following: 

I  •  Earned  value 

;  •  Schedule  performance  index 

i  •  Defect  density 

;  •  Peer  review  coverage 

:•  Test  or  verification  coverage 

:  •  Reliability  measures  (e.g.,  mean  time  to  failure) 

I  •  Quality  measures  (e.g.,  number  of  defects  by  severity/total  number  of  defects) 

;  •  Information  security  measures  (e.g.,  percentage  of  system  vulnerabilities  mitigated) 
i  •  Customer  satisfaction  trends 


Derived  measures  typically  are  expressed  as  ratios,  composite  indices,  or 
other  aggregate  summary  measures.  They  are  often  more  quantitatively 
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reliable  and  meaningfully  interpretable  than  the  base  measures  used  to 
generate  them. 

There  are  direct  relationships  among  information  needs,  measurement 
objectives,  measurement  categories,  base  measures,  and  derived 
measures.  This  direct  relationship  is  depicted  using  some  common 
examples  in  Table  MA.1 . 
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Table  MA.1:  Example  Measurement  Relationships 


Example  Project, 
Organizational,  or 
Business 
Objectives 

Information 

Need 

Measurement 

Objective 

Measurement 

Information 

Categories 

Exampie  Base 
Measures 

Exampie  Derived 
Measures 

Shorten  time  to 
delivery 

Be  first  to  market 
the  product 

What  is  the 
estimated 
delivery  time? 

Provide  insight 
into  schedule 
fluctuations  and 
progress 

Schedule  and 
progress 

Estimated  and 
actual  start  and  end 
dates  by  task 

Milestone  performance 

Percentage  of  project 
on  time 

Schedule  estimation 
accuracy 

Increase  market 
share  by  reducing 
costs  of  products 

How  accurate 
are  the  size 
and  cost 

Provide  insight 
into  actual  size 
and  costs 

Size  and  effort 

Estimated  and 
actual  effort  and 
size 

Productivity 

and  services 

estimates? 

compared  to  plan 

Effort  and  cost 

Estimated  and 
actual  cost 

Cost  performance 

Cost  variance 

Deliver  specified 
functionality 

Has  scope  or 
project  size 
grown? 

Provide  insight 
into  actual  size 
compared  to  plan, 
identify  unplanned 

Size  and 
stability 

Requirements  count 

Requirements  volatility 

Size  estimation 
accuracy 

growth 

Function  point  count 

Estimated  vs.  actual 
function  points 

Lines  of  code  count 

Amount  of  new, 
modified,  and  reused 
code 

Reduce  defects  in 
products  delivered 
to  the  customer  by 
10%  without 
affecting  cost 

Where  are 
defects  being 
inserted  and 
detected  prior 
to  delivery? 

Evaluate  the 
effectiveness  of 
defect  detection 
throughout  the 
product  lifecycle 

Quality 

Number  of  defects 
inserted  and 
detected  by  lifecycle 
phase 

Product  size 

Defect  containment  by 
lifecycle  phase 

Defect  density 

What  is  the 
cost  of  rework? 

Determine  the 
cost  of  correcting 
defects 

Cost 

Number  of  defects 
inserted  and 
detected  by  lifecycle 
phase 

Rework  costs 

Effort  hours  to 
correct  defects 

Labor  rates 

Reduce  information 

system 

vulnerabilities 

What  is  the 
magnitude  of 
open  system 
vulnerabilities? 

Evaluate  the 
effectiveness  of 
mitigating  system 
vulnerabilities 

Information 

Assurance 

Number  of  system 
vulnerabilities 
identified  and 
number  of  system 
vulnerabilities 
mitigated 

Percentage  of  system 
vulnerabilities 
mitigated 
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Example  Work  Products 

1 .  Specifications  of  base  and  derived  measures 
Subpractices 

1 .  Identify  candidate  measures  based  on  documented  measurement 
objectives. 

Measurement  objectives  are  refined  into  measures.  Identified  candidate  measures  are 
categorized  and  specified  by  name  and  unit  of  measure. 

2.  Maintain  traceability  of  measures  to  measurement  objectives. 

Interdependencies  among  candidate  measures  are  identified  to  enable  later  data 
validation  and  candidate  analyses  In  support  of  measurement  objectives. 

3.  Identify  existing  measures  that  already  address  measurement 
objectives. 

Specifications  for  measures  may  already  exist,  perhaps  established  for  other  purposes 
earlier  or  elsewhere  in  the  organization. 

4.  Specify  operational  definitions  for  measures. 

Operational  definitions  are  stated  in  precise  and  unambiguous  terms.  They  address 
two  important  criteria: 

•  Communication:  What  has  been  measured,  how  was  it  measured,  what  are  the  units  of 
measure,  and  what  has  been  included  or  excluded? 

•  Repeatability:  Can  the  measurement  be  repeated,  given  the  same  definition,  to  get  the 
same  results? 

5.  Prioritize,  review,  and  update  measures. 

Proposed  specifications  of  measures  are  reviewed  for  their  appropriateness  with 
potential  end  users  and  other  relevant  stakeholders.  Priorities  are  set  or  changed,  and 
specifications  of  measures  are  updated  as  necessary. 

SP  1 .3  Specify  Data  Collection  and  Storage  Procedures 

Specify  how  measurement  data  are  obtained  and  stored. 

Explicit  specification  of  collection  methods  helps  to  ensure  that  the  right 
data  are  collected  properly.  This  specification  can  also  help  further  clarify 
information  needs  and  measurement  objectives. 

Proper  attention  to  storage  and  retrieval  procedures  helps  to  ensure  that 
data  are  available  and  accessible  for  future  use. 

Example  Work  Products 

1 .  Data  collection  and  storage  procedures 

2.  Data  collection  tools 
Subpractices 

1 .  Identify  existing  sources  of  data  that  are  generated  from  current  work 
products,  processes,  or  transactions. 
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Existing  sources  of  data  may  have  been  identified  when  specifying  the  measures. 
Appropriate  collection  mechanisms  may  exist  whether  or  not  pertinent  data  have 
already  been  collected. 

2.  Identify  measures  for  which  data  are  needed  but  are  not  currently 
available. 

3.  Specify  how  to  collect  and  store  the  data  for  each  required  measure. 

Explicit  specifications  are  made  of  what,  how,  where,  and  when  data  will  be  collected 
and  stored  to  ensure  its  validity  and  to  support  later  use  for  analysis  and 
documentation  purposes. 

i  Questions  to  be  considered  typically  include  the  following: 

i  •  Have  the  frequency  of  collection  and  the  points  in  the  process  where  measurements 
;  will  be  made  been  determined? 

;  •  Has  the  timeline  that  is  required  to  move  measurement  results  from  points  of  collection 
i  to  repositories,  other  databases,  or  end  users  been  established? 

;  •  Who  is  responsible  for  obtaining  data? 

;  •  Who  is  responsible  for  data  storage,  retrieval,  and  security? 
i  •  Have  necessai7  supporting  tools  been  developed  or  acquired? 

4.  Create  data  collection  mechanisms  and  process  guidance. 

Data  collection  and  storage  mechanisms  are  well  integrated  with  other  normal  work 
processes.  Data  collection  mechanisms  can  include  manual  or  automated  forms  and 
templates.  Clear,  concise  guidance  on  correct  procedures  is  available  to  those  who 
are  responsible  for  doing  the  work.  Training  is  provided  as  needed  to  clarify  processes 
required  for  the  collection  of  complete  and  accurate  data  and  to  minimize  the  burden 
on  those  who  provide  and  record  data. 

5.  Support  automatic  collection  of  data  as  appropriate  and  feasible. 

;  Examples  of  such  automated  support  include  the  following: 

I  •  Time  stamped  activity  logs 
I  •  Static  or  dynamic  analyses  of  artifacts 

6.  Prioritize,  review,  and  update  data  collection  and  storage  procedures. 

Proposed  procedures  are  reviewed  for  their  appropriateness  and  feasibility  with  those 
who  are  responsible  for  providing,  collecting,  and  storing  data.  They  also  may  have 
useful  insights  about  how  to  improve  existing  processes  or  may  be  able  to  suggest 
other  useful  measures  or  analyses. 

7.  Update  measures  and  measurement  objectives  as  necessary. 

SP  1 .4  Specify  Analysis  Procedures 

Specify  how  measurement  data  are  analyzed  and  communicated. 

Specifying  analysis  procedures  in  advance  ensures  that  appropriate 
analyses  will  be  conducted  and  reported  to  address  documented 
measurement  objectives  (and  thereby  the  information  needs  and  objectives 
on  which  they  are  based).  This  approach  also  provides  a  check  that 
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necessary  data  will,  in  fact,  be  collected.  Analysis  procedures  should 
account  for  the  quality  (e.g.,  age,  reliability)  of  all  data  that  enter  into  an 
analysis  (whether  from  the  project,  organization’s  measurement  repository, 
or  other  source).  The  quality  of  data  should  be  considered  to  help  select  the 
appropriate  analysis  procedure  and  evaluate  the  results  of  the  analysis. 

Example  Work  Products 

1 .  Analysis  specifications  and  procedures 

2.  Data  analysis  tools 
Subpractices 

1 .  Specify  and  prioritize  the  analyses  to  be  conducted  and  the  reports  to 
be  prepared. 

Early  on,  pay  attention  to  the  analyses  to  be  conducted  and  to  the  manner  in  which 
results  will  be  reported.  These  analyses  and  reports  should  meet  the  following  criteria: 

•  The  analyses  explicitly  address  the  documented  measurement  objectives. 

•  Presentation  of  results  is  clearly  understandable  by  the  audiences  to  whom  the  results 
are  addressed. 

Priorities  may  have  to  be  set  for  available  resources. 

2.  Select  appropriate  data  analysis  methods  and  tools, 
i  Issues  to  be  considered  typically  include  the  following: 

;  •  Choice  of  visual  display  and  other  presentation  techniques  (e.g.,  pie  charts,  bar  charts, 
i  histograms,  radar  charts,  line  graphs,  scatter  plots,  tables) 

;  •  Choice  of  appropriate  descriptive  statistics  (e.g.,  arithmetic  mean,  median,  mode) 

;  •  Decisions  about  statistical  sampling  criteria  when  it  is  impossible  or  unnecessary  to 
i  examine  every  data  element 

I  •  Decisions  about  how  to  handle  analysis  in  the  presence  of  missing  data  elements 
I  •  Selection  of  appropriate  analysis  tools 

;  Descriptive  statistics  are  typically  used  in  data  analysis  to  do  the  following: 

I  •  Examine  distributions  of  specified  measures  (e.g.,  central  tendency,  extent  of  variation, 
I  data  points  exhibiting  unusual  variation) 

I  •  Examine  interrelationships  among  specified  measures  (e.g.,  comparisons  of  defects  by 
I  phase  of  the  product's  lifecycle,  comparisons  of  defects  by  product  component) 

I  •  Display  changes  over  time 


Refer  to  the  Select  Measures  and  Analytic  Techniques  specific  practice 
and  Monitor  the  Performance  of  Selected  Subprocesses  specific 
practice  in  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  appropriate  use  of  statistical  techniques  and 
understanding  variation. 

3.  Specify  administrative  procedures  for  analyzing  data  and 
communicating  results. 
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Issues  to  be  considered  typically  include  the  following: 

•  Identifying  the  persons  and  groups  responsible  for  analyzing  the  data  and  presenting 
the  results 

•  Determining  the  timeline  to  analyze  the  data  and  present  the  results 

•  Determining  the  venues  for  communicating  the  results  (e.g.,  progress  reports, 
transmittal  memos,  written  reports,  staff  meetings) 


4.  Review  and  update  the  proposed  content  and  format  of  specified 
analyses  and  reports. 

All  of  the  proposed  content  and  format  are  subject  to  review  and  revision,  including 
analytic  methods  and  tools,  administrative  procedures,  and  priorities.  Relevant 
stakeholders  consulted  should  include  end  users,  sponsors,  data  analysts,  and  data 
providers. 

5.  Update  measures  and  measurement  objectives  as  necessary. 

Just  as  measurement  needs  drive  data  analysis,  clarification  of  analysis  criteria  can 
affect  measurement.  Specifications  for  some  measures  may  be  refined  further  based 
on  specifications  established  for  data  analysis  procedures.  Other  measures  may  prove 
unnecessary  or  a  need  for  additional  measures  may  be  recognized. 

Specifying  how  measures  will  be  analyzed  and  reported  can  also  suggest  the  need  for 
refining  measurement  objectives  themselves. 

6.  Specify  criteria  for  evaluating  the  utility  of  analysis  results  and  for 
evaluating  the  conduct  of  measurement  and  analysis  activities. 

^ - 

I  Criteria  for  evaluating  the  utility  of  the  analysis  might  address  the  extent  to  which  the 

i  following  apply: 

I  •  The  results  are  provided  in  a  timely  manner,  understandable,  and  used  for  decision 
;  making. 

;  •  The  work  does  not  cost  more  to  perform  than  is  justified  by  the  benefits  it  provides. 


f. - - 

I  Criteria  for  evaluating  the  conduct  of  the  measurement  and  analysis  might  include  the 
;  extent  to  which  the  following  apply: 

i  •  The  amount  of  missing  data  or  the  number  of  flagged  inconsistencies  is  beyond 
i  specified  thresholds. 

i  •  There  is  selection  bias  in  sampling  (e.g.,  only  satisfied  end  users  are  surveyed  to 
;  evaluate  end-user  satisfaction,  only  unsuccessful  projects  are  evaluated  to  determine 
;  overall  productivity). 

I  •  Measurement  data  are  repeatable  (e.g.,  statistically  reliable). 

;  •  Statistical  assumptions  have  been  satisfied  (e.g.,  about  the  distribution  of  data,  about 

I  appropriate  measurement  scales). 
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SG  2  Provide  Measurement  Results 

Measurement  results,  which  address  identified  information  needs  and 
objectives,  are  provided. 

The  primary  reason  for  conducting  measurement  and  analysis  is  to  address 
identified  information  needs  derived  from  project,  organizational,  and 
business  objectives.  Measurement  results  based  on  objective  evidence  can 
help  to  monitor  progress  and  performance,  fulfill  obligations  documented  in 
a  supplier  agreement,  make  informed  management  and  technical  decisions, 
and  enable  corrective  actions  to  be  taken. 

SP  2.1  Obtain  Measurement  Data 

Obtain  specified  measurement  data. 

The  data  necessary  for  analysis  are  obtained  and  checked  for 
completeness  and  integrity. 

Example  Work  Products 

1 .  Base  and  derived  measurement  data  sets 

2.  Results  of  data  integrity  tests 

Subpractices 

1 .  Obtain  data  for  base  measures. 

Data  are  collected  as  necessary  for  previously  used  and  newly  specified  base 
measures.  Existing  data  are  gathered  from  project  records  or  elsewhere  In  the 
organization. 

2.  Generate  data  for  derived  measures. 

Values  are  newly  calculated  for  all  derived  measures. 

3.  Perform  data  integrity  checks  as  close  to  the  source  of  data  as 
possible. 

All  measurements  are  subject  to  error  In  specifying  or  recording  data.  It  is  always 
better  to  Identify  these  errors  and  sources  of  missing  data  early  In  the  measurement 
and  analysis  cycle. 

Checks  can  Include  scans  for  missing  data,  out-of-bounds  data  values,  and  unusual 
patterns  and  correlation  across  measures.  It  Is  particularly  Important  to  do  the 
following: 

•  Test  and  correct  for  Inconsistency  of  classifications  made  by  human  judgment  (I.e.,  to 
determine  how  frequently  people  make  differing  classification  decisions  based  on  the 
same  Information,  otherwise  known  as  “Inter-coder  reliability”). 

•  Empirically  examine  the  relationships  among  measures  that  are  used  to  calculate 
additional  derived  measures.  Doing  so  can  ensure  that  Important  distinctions  are  not 
overlooked  and  that  derived  measures  convey  their  Intended  meanings  (otherwise 
known  as  “criterion  validity”). 
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SP  2.2  Analyze  Measurement  Data 

Analyze  and  interpret  measurement  data. 

Measurement  data  are  analyzed  as  planned,  additional  analyses  are 
conducted  as  necessary,  results  are  reviewed  with  relevant  stakeholders, 
and  necessary  revisions  for  future  analyses  are  noted. 

Example  Work  Products 

1 .  Analysis  results  and  draft  reports 

Subpractices 

1 .  Conduct  initial  analyses,  interpret  results,  and  draw  preliminary 
conclusions. 

The  results  of  data  analyses  are  rarely  self  evident.  Criteria  for  interpreting  results  and 
drawing  conclusions  should  be  stated  explicitly. 

2.  Conduct  additional  measurement  and  analysis  as  necessary  and 
prepare  results  for  presentation. 

Results  of  planned  analyses  can  suggest  (or  require)  additional,  unanticipated 
analyses.  In  addition,  these  analyses  can  identify  needs  to  refine  existing  measures,  to 
calculate  additional  derived  measures,  or  even  to  collect  data  for  additional  base 
measures  to  properly  complete  the  planned  analysis.  Similarly,  preparing  initial  results 
for  presentation  can  identify  the  need  for  additional,  unanticipated  analyses. 

3.  Review  initial  results  with  relevant  stakeholders. 

It  may  be  appropriate  to  review  initial  interpretations  of  results  and  the  way  in  which 
these  results  are  presented  before  disseminating  and  communicating  them  widely. 

Reviewing  the  initial  results  before  their  release  can  prevent  needless 
misunderstandings  and  lead  to  improvements  in  the  data  analysis  and  presentation. 

Relevant  stakeholders  with  whom  reviews  may  be  conducted  include  intended  end 
users,  sponsors,  data  analysts,  and  data  providers. 

4.  Refine  criteria  for  future  analyses. 

Lessons  that  can  improve  future  efforts  are  often  learned  from  conducting  data 
analyses  and  preparing  results.  Similarly,  ways  to  improve  measurement  specifications 
and  data  collection  procedures  can  become  apparent  as  can  ideas  for  refining 
identified  information  needs  and  objectives. 

SP  2.3  Store  Data  and  Results 

Manage  and  store  measurement  data,  measurement  specifications, 
and  analysis  results. 

Storing  measurement  related  information  enables  its  timely  and  cost 
effective  use  as  historical  data  and  results.  The  information  also  is  needed 
to  provide  sufficient  context  for  interpretation  of  data,  measurement  criteria, 
and  analysis  results. 
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Information  stored  typically  includes  the  following: 

•  Measurement  plans 

•  Specifications  of  measures 

•  Sets  of  data  that  were  collected 

•  Analysis  reports  and  presentations 

•  Retention  period  for  data  stored 


Stored  information  contains  or  refers  to  other  information  needed  to 
understand  and  interpret  the  measures  and  to  assess  them  for 
reasonableness  and  applicability  (e.g.,  measurement  specifications  used  on 
different  projects  when  comparing  across  projects). 

Typically,  data  sets  for  derived  measures  can  be  recalculated  and  need  not 
be  stored.  However,  it  may  be  appropriate  to  store  summaries  based  on 
derived  measures  (e.g.,  charts,  tables  of  results,  report  text). 

Interim  analysis  results  need  not  be  stored  separately  if  they  can  be 
efficiently  reconstructed. 

Projects  can  choose  to  store  project  specific  data  and  results  in  a  project 
specific  repository.  When  data  are  shared  across  projects,  the  data  can 
reside  in  the  organization’s  measurement  repository. 

Refer  to  the  Configuration  Management  process  area  for  more  information 
about  estabiishing  a  configuration  management  system. 

Refer  to  the  Estabiish  the  Organization’s  Measurement  Repository  specific 
practice  in  the  Organizationai  Process  Definition  process  area  for  more 
information  about  establishing  the  organization’s  measurement  repository. 

Example  Work  Products 

1 .  Stored  data  inventory 

Subpractices 

1 .  Review  data  to  ensure  their  completeness,  integrity,  accuracy,  and 
currency. 

2.  Store  data  according  to  data  storage  procedures. 

3.  Make  stored  contents  available  for  use  only  to  appropriate  groups  and 
staff  members. 

4.  Prevent  stored  information  from  being  used  inappropriately. 

f. - 

I  Examples  of  ways  to  prevent  the  inappropriate  use  of  data  and  related  information 
;  include  controlling  access  to  data  and  educating  people  on  the  appropriate  use  of 
:  data. 
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I  Examples  of  the  inappropriate  use  of  data  include  the  following: 

I  •  Disclosure  of  information  provided  in  confidence 

I  •  Faulty  interpretations  based  on  incomplete,  out-of-context,  or  otherwise  misleading 
I  information 

I  •  Measures  used  to  improperly  evaluate  the  performance  of  people  or  to  rank  projects 
[  •  Impugning  the  integrity  of  individuals 


SP  2.4  Communicate  Results 

Communicate  results  of  measurement  and  analysis  activities  to  all 
relevant  stakeholders. 

The  results  of  the  measurement  and  analysis  process  are  communicated  to 
relevant  stakeholders  in  a  timely  and  usable  fashion  to  support  decision 
making  and  assist  in  taking  corrective  action. 

Relevant  stakeholders  include  intended  end  users,  sponsors,  data  analysts, 
and  data  providers. 

Example  Work  Products 

1 .  Delivered  reports  and  related  analysis  results 

2.  Contextual  information  or  guidance  to  help  interpret  analysis  results 
Subpractices 

1 .  Keep  relevant  stakeholders  informed  of  measurement  results  in  a 
timely  manner. 

To  the  extent  possible  and  as  part  of  the  normal  way  they  do  business,  users  of 
measurement  results  are  kept  personally  involved  in  setting  objectives  and  deciding  on 
plans  of  action  for  measurement  and  analysis.  Users  are  regularly  kept  informed  of 
progress  and  interim  results. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  conducting  progress  reviews. 

2.  Assist  relevant  stakeholders  in  understanding  results. 

Results  are  communicated  in  a  clear  and  concise  manner  appropriate  to  relevant 
stakeholders.  Results  are  understandable,  easily  interpretable,  and  clearly  tied  to 
identified  information  needs  and  objectives. 

The  data  analyzed  are  often  not  self  evident  to  practitioners  who  are  not  measurement 
experts.  The  communication  of  results  should  be  clear  about  the  following: 

•  How  and  why  base  and  derived  measures  were  specified 

•  How  data  were  obtained 

•  How  to  interpret  results  based  on  the  data  analysis  methods  used 

•  How  results  address  information  needs 
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I  Examples  of  actions  taken  to  help  others  to  understand  results  include  the  following: 

I  •  Discussing  the  results  with  relevant  stakeholders 
I  •  Providing  background  and  explanation  in  a  document 
I  •  Briefing  users  on  results 

•  Providing  training  on  the  appropriate  use  and  understanding  of  measurement  results 
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ORGANIZATIONAL  PROCESS  DEFINITION 

A  Process  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Organizational  Process  Definition  (OPD)  is  to  establish  and 
maintain  a  usable  set  of  organizational  process  assets,  work  environment 
standards,  and  rules  and  guidelines  for  teams. 


Introductory  Notes 


Organizational  process  assets  enable  consistent  process  execution  across 
the  organization  and  provide  a  basis  for  cumulative,  long-term  benefits  to 
the  organization.  (See  the  definition  of  “organizational  process  assets”  in 
the  glossary.) 

The  organization’s  process  asset  library  supports  organizational  learning 
and  process  improvement  by  allowing  the  sharing  of  best  practices  and 
lessons  learned  across  the  organization.  (See  the  definition  of 
“organizational  process  assets”  in  the  glossary.) 

The  organization’s  set  of  standard  processes  also  describes  standard 
interactions  with  suppliers.  Supplier  interactions  are  characterized  by  the 
following  typical  items:  deliverables  expected  from  suppliers,  acceptance 
criteria  applicable  to  those  deliverables,  standards  (e.g.,  architecture  and 
technology  standards),  and  standard  milestone  and  progress  reviews. 

The  organization’s  “set  of  standard  processes”  is  tailored  by  projects  to 
create  their  defined  processes.  Other  organizational  process  assets  are 
used  to  support  tailoring  and  implementing  defined  processes.  Work 
environment  standards  are  used  to  guide  the  creation  of  project  work 
environments.  Rules  and  guidelines  for  teams  are  used  to  aid  in  their 
structuring,  formation,  and  operation. 

A  “standard  process”  is  composed  of  other  processes  (i.e.,  subprocesses) 
or  process  elements.  A  “process  element”  is  the  fundamental  (i.e.,  atomic) 
unit  of  process  definition  that  describes  activities  and  tasks  to  consistently 
perform  work.  The  process  architecture  provides  rules  for  connecting  the 
process  elements  of  a  standard  process.  The  organization’s  set  of  standard 
processes  can  include  multiple  process  architectures. 

(See  the  definitions  of  “standard  process,”  “process  architecture,” 
“subprocess,”  and  “process  element”  in  the  glossary.) 
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Organizational  process  assets  can  be  organized  in  many  ways,  depending  on  the 
implementation  of  the  Organizational  Process  Definition  process  area.  Examples  include  the 
following: 

•  Descriptions  of  lifecycle  models  can  be  part  of  the  organization’s  set  of  standard 
processes  or  they  can  be  documented  separately. 

•  The  organization’s  set  of  standard  processes  can  be  stored  in  the  organization’s 
process  asset  library  or  it  can  be  stored  separately. 

•  A  single  repository  can  contain  both  measurements  and  process  related 
documentation,  or  they  can  be  stored  separately. 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  deploying  organizational  process  assets. 


Specific  Goal  and  Practice  Summary 

SG  1  Establish  Organizational  Process  Assets 
SP1.1  Establish  standard  Processes 

SP  1 .2  Establish  Lifecycle  Model  Descriptions 

SP  1 .3  Establish  Tailoring  Criteria  and  Guidelines 
SP  1 .4  Establish  the  Organization’s  Measurement  Repository 
SP  1 .5  Establish  the  Organization's  Process  Asset  Library 
SP  1 .6  Establish  Work  Environment  Standards 
SP  1 .7  Establish  Rules  and  Guidelines  for  Teams 


Specific  Practices  by  Goal 


SG  1 _ Establish  Organizational  Process  Assets _ 

A  set  of  organizational  process  assets  is  established  and  maintained. 

SP  1.1  Establish  Standard  Processes 

Establish  and  maintain  the  organization’s  set  of  standard 
processes. 

Standard  processes  can  be  defined  at  multiple  levels  in  an  enterprise  and 
they  can  be  related  hierarchically.  For  example,  an  enterprise  can  have  a 
set  of  standard  processes  that  is  tailored  by  individual  organizations  (e.g.,  a 
division,  a  site)  in  the  enterprise  to  establish  their  set  of  standard 
processes.  The  set  of  standard  processes  can  also  be  tailored  for  each  of 
the  organization’s  business  areas,  product  lines,  or  standard  services.  Thus 
the  organization’s  set  of  standard  processes  can  refer  to  the  standard 
processes  established  at  the  organization  level  and  standard  processes 
that  may  be  established  at  lower  levels,  although  some  organizations  may 
have  only  one  level  of  standard  processes.  (See  the  definitions  of  “standard 
process”  and  “organization’s  set  of  standard  processes”  in  the  glossary.) 

Multiple  standard  processes  may  be  needed  to  address  the  needs  of 
different  application  domains,  lifecycle  models,  methodologies,  and  tools. 
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The  organization’s  set  of  standard  processes  contains  process  elements 
(e.g.,  a  work  product  size  estimating  element)  that  may  be  interconnected 
according  to  one  or  more  process  architectures  that  describe  relationships 
among  process  elements. 

The  organization’s  set  of  standard  processes  typically  includes  technical, 
management,  administrative,  support,  and  organizational  processes. 

The  organization’s  set  of  standard  processes  should  collectively  cover  all 
processes  needed  by  the  organization  and  projects,  including  those 
processes  addressed  by  the  process  areas  at  maturity  level  2. 

Example  Work  Products 

1 .  Organization’s  set  of  standard  processes 
Subpractices 

1 .  Decompose  each  standard  process  into  constituent  process  elements 
to  the  detail  needed  to  understand  and  describe  the  process. 

Each  process  element  covers  a  closely  related  set  of  activities.  The  descriptions  of 
process  elements  may  be  templates  to  be  filled  In,  fragments  to  be  completed, 
abstractions  to  be  refined,  or  complete  descriptions  to  be  tailored  or  used  unmodified. 
These  elements  are  described  In  such  detail  that  the  process,  when  fully  defined,  can 
be  consistently  performed  by  appropriately  trained  and  skilled  people. 

I  Examples  of  process  elements  Include  the  following: 

I  •  Template  for  generating  work  product  size  estimates 

:  •  Description  of  work  product  design  methodology 

i  •  Tallorable  peer  review  methodology 

i  •  Template  for  conducting  management  reviews 

i  •  Templates  or  task  flows  embedded  In  workflow  tools 

i  •  Description  of  methods  for  prequallfying  suppliers  as  preferred  suppliers 


2.  Specify  the  critical  attributes  of  each  process  element. 

i  Examples  of  critical  attributes  Include  the  following: 

;  •  Process  roles 
;  •  Applicable  standards 

i  •  Applicable  procedures,  methods,  tools,  and  resources 
i  •  Process  performance  objectives 
I  •  Entry  criteria 

I  •  Inputs 

;  •  Verification  points  (e.g.,  peer  reviews) 

;  •  Outputs 

I  •  Interfaces 

I  •  Exit  criteria 

I  •  Product  and  process  measures 


3.  Specify  relationships  among  process  elements. 
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Examples  of  relationships  include  the  following: 

•  Order  of  the  process  elements 

•  Interfaces  among  process  elements 

•  Interfaces  with  external  processes 

•  Interdependencies  among  process  elements 


The  rules  for  describing  relationships  among  process  elements  are  referred  to  as  the 
‘‘process  architecture.”  The  process  architecture  covers  essential  requirements  and 
guidelines.  Detailed  specifications  of  these  relationships  are  covered  in  descriptions  of 
defined  processes  that  are  tailored  from  the  organization’s  set  of  standard  processes. 

4.  Ensure  that  the  organization’s  set  of  standard  processes  adheres  to 
applicable  policies,  standards,  and  models. 

Adherence  to  applicable  process  standards  and  models  is  typically  demonstrated  by 
developing  a  mapping  from  the  organization’s  set  of  standard  processes  to  relevant 
process  standards  and  models.  This  mapping  is  a  useful  input  to  future  appraisals. 

5.  Ensure  that  the  organization’s  set  of  standard  processes  satisfies 
process  needs  and  objectives  of  the  organization. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  establishing  organizational  process  needs. 

6.  Ensure  that  there  is  appropriate  integration  among  processes  that  are 
included  in  the  organization’s  set  of  standard  processes. 

7.  Document  the  organization’s  set  of  standard  processes. 

8.  Conduct  peer  reviews  on  the  organization’s  set  of  standard  processes. 

Refer  to  the  Verification  process  area  for  more  information  about 
performing  peer  reviews. 

9.  Revise  the  organization’s  set  of  standard  processes  as  necessary. 

I  Examples  of  when  the  organization's  set  of  standard  processes  may  need  to  be 
i  revised  include  the  following: 

;  •  When  improvements  to  the  process  are  identified 

;  •  When  causal  analysis  and  resolution  data  indicate  that  a  process  change  is  needed 

I  •  When  process  improvement  proposals  are  selected  for  deployment  across  the 
I  organization 

I  •  When  the  organization’s  process  needs  and  objectives  are  updated 


SP  1.2  Establish  Lifecycle  Model  Descriptions 

Establish  and  maintain  descriptions  of  lifecycle  models  approved 
for  use  in  the  organization. 

Lifecycle  models  can  be  developed  for  a  variety  of  customers  or  in  a  variety 
of  situations,  since  one  lifecycle  model  may  not  be  appropriate  for  all 
situations.  Lifecycle  models  are  often  used  to  define  phases  of  the  project. 
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Also,  the  organization  can  define  different  lifecycle  models  for  each  type  of 
product  and  service  it  delivers. 

Example  Work  Products 

1 .  Descriptions  of  lifecycle  models 

Subpractices 

1 .  Select  lifecycle  models  based  on  the  needs  of  projects  and  the 
organization. 

i  Examples  of  project  lifecycle  models  include  the  following: 

;  •  Waterfall  or  Serial 
;  •  Spiral 
i  •  Evolutionary 
i  •  Incremental 
I  •  Iterative 

2.  Document  descriptions  of  lifecycle  models. 

Lifecycle  models  can  be  documented  as  part  of  the  organization’s  standard  process 
descriptions  or  they  can  be  documented  separately. 

3.  Conduct  peer  reviews  on  lifecycle  models. 

Refer  to  the  Verification  process  area  for  more  information  about 
performing  peer  reviews. 

4.  Revise  the  descriptions  of  lifecycle  models  as  necessary. 

SP  1.3  Establish  Tailoring  Criteria  and  Guidelines 

Establish  and  maintain  tailoring  criteria  and  guidelines  for  the 
organization’s  set  of  standard  processes. 

Tailoring  criteria  and  guidelines  describe  the  following: 

•  How  the  organization’s  set  of  standard  processes  and  organizational 
process  assets  are  used  to  create  defined  processes 

•  Requirements  that  must  be  satisfied  by  defined  processes  (e.g.,  the 
subset  of  organizational  process  assets  that  are  essential  for  any 
defined  process) 

•  Options  that  can  be  exercised  and  criteria  for  selecting  among  options 

•  Procedures  that  must  be  followed  in  performing  and  documenting 
process  tailoring 

;  Examples  of  reasons  for  tailoring  include  the  following: 

;  •  Adapting  the  process  to  a  new  product  line  or  work  environment 

i  •  Elaborating  the  process  description  so  that  the  resulting  defined  process  can  be 
i  performed 

I  •  Customizing  the  process  for  an  application  or  class  of  similar  applications 
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Flexibility  in  tailoring  and  defining  processes  is  balanced  with  ensuring 
appropriate  consistency  of  processes  across  the  organization.  Flexibility  is 
needed  to  address  contextual  variables  such  as  the  domain;  the  nature  of 
the  customer;  cost,  schedule,  and  quality  tradeoffs;  the  technical  difficulty  of 
the  work;  and  the  experience  of  the  people  implementing  the  process. 
Consistency  across  the  organization  is  needed  so  that  organizational 
standards,  objectives,  and  strategies  are  appropriately  addressed,  and 
process  data  and  lessons  learned  can  be  shared. 

Tailoring  is  a  critical  activity  that  allows  controlled  changes  to  processes 
due  to  the  specific  needs  of  a  project  or  a  part  of  the  organization. 

Processes  and  process  elements  that  are  directly  related  to  critical 
business  objectives  should  usually  be  defined  as  mandatory,  but  processes 
and  process  elements  that  are  less  critical  or  only  indirectly  affect  business 
objectives  may  allow  for  more  tailoring. 

The  amount  of  tailoring  could  also  depend  on  the  project’s  lifecycle  model, 
the  use  of  suppliers,  and  other  factors. 

Tailoring  criteria  and  guidelines  can  allow  for  using  a  standard  process  “as 
is,”  with  no  tailoring. 

Example  Work  Products 

1 .  Tailoring  guidelines  for  the  organization’s  set  of  standard  processes 
Subpractices 

1 .  Specify  selection  criteria  and  procedures  for  tailoring  the  organization’s 
set  of  standard  processes. 

;  Examples  of  criteria  and  procedures  inciude  the  foiiowing: 

i  •  Criteria  for  selecting  lifecycle  models  from  the  ones  approved  by  the  organization 

I  •  Criteria  for  selecting  process  elements  from  the  organization's  set  of  standard 
;  processes 

I  •  Procedures  for  tailoring  selected  lifecycle  models  and  process  elements  to 
I  accommodate  process  characteristics  and  needs 

;  •  Procedures  for  adapting  the  organization's  common  measures  to  address  information 
I  needs 

f. - 

I  Examples  of  tailoring  include  the  following: 

I  •  Modifying  a  lifecycle  model 
I  •  Combining  elements  of  different  lifecycle  models 
I  •  Modifying  process  elements 
I  •  Replacing  process  elements 
•  Reordering  process  elements 

2.  Specify  the  standards  used  for  documenting  defined  processes. 

3.  Specify  the  procedures  used  for  submitting  and  obtaining  approval  of 
waivers  from  the  organization’s  set  of  standard  processes. 
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4.  Document  tailoring  guidelines  for  the  organization’s  set  of  standard 
processes. 

5.  Conduct  peer  reviews  on  the  tailoring  guidelines. 

Refer  to  the  Verification  process  area  for  more  information  about 
performing  peer  reviews. 

6.  Revise  tailoring  guidelines  as  necessary. 

SP  1.4  Establish  the  Organization’s  Measurement  Repository 

Establish  and  maintain  the  organization’s  measurement  repository. 

Refer  to  the  Use  Organizationai  Process  Assets  for  Pianning  Project 
Activities  specific  practice  in  the  Integrated  Project  Management  process 
area  for  more  information  about  the  use  of  the  organization’s  measurement 
repository  in  pianning  project  activities. 

The  repository  contains  both  product  and  process  measures  that  are 
related  to  the  organization’s  set  of  standard  processes.  It  also  contains  or 
refers  to  information  needed  to  understand  and  interpret  measures  and  to 
assess  them  for  reasonableness  and  applicability.  For  example,  the 
definitions  of  measures  are  used  to  compare  similar  measures  from 
different  processes. 

Example  Work  Products 

1 .  Definition  of  the  common  set  of  product  and  process  measures  for  the 
organization’s  set  of  standard  processes 

2.  Design  of  the  organization’s  measurement  repository 

3.  Organization’s  measurement  repository  (i.e.,  the  repository  structure, 
support  environment) 

4.  Organization’s  measurement  data 
Subpractices 

1 .  Determine  the  organization’s  needs  for  storing,  retrieving,  and 
analyzing  measurements. 

2.  Define  a  common  set  of  process  and  product  measures  for  the 
organization’s  set  of  standard  processes. 

Measures  in  the  common  set  are  selected  for  their  ability  to  provide  visibility  into 
processes  critical  to  achieving  business  objectives  and  to  focus  on  process  elements 
significantly  Impacting  cost,  schedule,  and  performance  within  a  project  and  across  the 
organization.  The  common  set  of  measures  can  vary  for  different  standard  processes. 

Measures  defined  include  the  ones  related  to  agreement  management,  some  of  which 
may  need  to  be  collected  from  suppliers. 

Operational  definitions  for  measures  specify  procedures  for  collecting  valid  data  and 
the  point  In  the  process  where  data  will  be  collected. 
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Examples  of  classes  of  commonly  used  measures  Include  the  following: 

•  Estimates  of  work  product  size  (e.g.,  pages) 

•  Estimates  of  effort  and  cost  (e.g.,  person  hours) 

•  Actual  measures  of  size,  effort,  and  cost 

•  Test  coverage 

•  Reliability  measures  (e.g.,  mean  time  to  failure) 

•  Quality  measures  (e.g.,  number  of  defects  found,  severity  of  defects) 

•  Peer  review  coverage 


3.  Design  and  implement  the  measurement  repository. 

Functions  of  the  measurement  repository  include  the  following: 

•  Supporting  effective  comparison  and  interpretation  of  measurement  data  among 
projects 

•  Providing  sufficient  context  to  allow  a  new  project  to  quickly  identify  and  access 
data  in  the  repository  for  similar  projects 

•  Enabling  projects  to  improve  the  accuracy  of  their  estimates  by  using  their  own 
and  other  projects’  historical  data 

•  Aiding  in  the  understanding  of  process  performance 

•  Supporting  potential  statistical  management  of  processes  or  subprocesses,  as 
needed 

4.  Specify  procedures  for  storing,  updating,  and  retrieving  measures. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  specifying  data  collection  and  storage  procedures. 

5.  Conduct  peer  reviews  on  definitions  of  the  common  set  of  measures 
and  procedures  for  storing,  updating,  and  retrieving  measures. 

Refer  to  the  Verification  process  area  for  more  information  about 
performing  peer  reviews. 

6.  Enter  specified  measures  into  the  repository. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  specifying  measures. 

7.  Make  the  contents  of  the  measurement  repository  available  for  use  by 
the  organization  and  projects  as  appropriate. 

8.  Revise  the  measurement  repository,  the  common  set  of  measures,  and 
procedures  as  the  organization’s  needs  change. 
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Examples  of  when  the  common  set  of  measures  may  need  to  be  revised  include  the 
following: 

•  New  processes  are  added 

•  Processes  are  revised  and  new  measures  are  needed 

•  Finer  granularity  of  data  is  required 

•  Greater  visibility  into  the  process  is  required 

•  Measures  are  retired 


SP  1.5  Establish  the  Organization’s  Process  Asset  Library 

Establish  and  maintain  the  organization’s  process  asset  library. 

I  Examples  of  items  to  be  stored  in  the  organization’s  process  asset  library  include  the 
;  following: 

;  •  Organizational  policies 

i  •  Process  descriptions 

;  •  Procedures  (e.g.,  estimating  procedure) 

i  •  Development  plans 

:  •  Acquisition  plans 

I  •  Quality  assurance  plans 

;  •  Training  materials 

i  •  Process  aids  (e.g.,  checklists) 

;  •  Lessons  learned  reports 


Example  Work  Products 

1 .  Design  of  the  organization’s  process  asset  library 

2.  The  organization’s  process  asset  library 

3.  Selected  items  to  be  included  in  the  organization’s  process  asset 
library 

4.  The  catalog  of  items  in  the  organization’s  process  asset  library 
Subpractices 

1 .  Design  and  implement  the  organization’s  process  asset  library, 
including  the  library  structure  and  support  environment. 

2.  Specify  criteria  for  including  items  in  the  library. 

Items  are  selected  based  primarily  on  their  relationship  to  the  organization’s  set  of 
standard  processes. 

3.  Specify  procedures  for  storing,  updating,  and  retrieving  items. 

4.  Enter  selected  items  into  the  library  and  catalog  them  for  easy 
reference  and  retrieval. 

5.  Make  items  available  for  use  by  projects. 

6.  Periodically  review  the  use  of  each  item. 
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7.  Revise  the  organization’s  process  asset  library  as  necessary. 

I  Examples  of  when  the  library  may  need  to  be  revised  include  the  following: 

I  •  New  Items  are  added 
I  •  Items  are  retired 
•  Current  versions  of  Items  are  changed 


SP  1 .6  Establish  Work  Environment  Standards 

Establish  and  maintain  work  environment  standards. 

Work  environment  standards  allow  the  organization  and  projects  to  benefit 
from  common  tools,  training,  and  maintenance,  as  well  as  cost  savings  from 
volume  purchases.  Work  environment  standards  address  the  needs  of  all 
stakeholders  and  consider  productivity,  cost,  availability,  security,  and 
workplace  health,  safety,  and  ergonomic  factors.  Work  environment 
standards  can  include  guidelines  for  tailoring  and  the  use  of  waivers  that 
allow  adaptation  of  the  project’s  work  environment  to  meet  needs. 

:  Examples  of  work  environment  standards  Include  the  following: 

i  •  Procedures  for  the  operation,  safety,  and  security  of  the  work  environment 

I  •  Standard  workstation  hardware  and  software 

I  •  Standard  application  software  and  tailoring  guidelines  for  It 

;  •  Standard  production  and  calibration  equipment 

i  •  Process  for  requesting  and  approving  tailoring  or  waivers 


Example  Work  Products 

1 .  Work  environment  standards 

Subpractices 

1 .  Evaluate  commercially  available  work  environment  standards 
appropriate  for  the  organization. 

2.  Adopt  existing  work  environment  standards  and  develop  new  ones  to 
fill  gaps  based  on  the  organization’s  process  needs  and  objectives. 

SP  1 .7  Establish  Rules  and  Guidelines  for  Teams 

Establish  and  maintain  organizational  rules  and  guidelines  for  the 
structure,  formation,  and  operation  of  teams. 

Operating  rules  and  guidelines  for  teams  define  and  control  how  teams  are 
created  and  how  they  interact  to  accomplish  objectives.  Team  members 
should  understand  the  standards  for  work  and  participate  according  to 
those  standards. 

When  establishing  rules  and  guidelines  for  teams,  ensure  they  comply  with 
all  local  and  national  regulations  or  laws  that  can  affect  the  use  of  teams. 

Structuring  teams  involves  defining  the  number  of  teams,  the  type  of  each 
team,  and  how  each  team  relates  to  the  others  in  the  structure.  Forming 
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teams  involves  chartering  each  team,  assigning  team  members  and  team 
leaders,  and  providing  resources  to  each  team  to  accomplish  work. 

Example  Work  Products 

1 .  Rules  and  guidelines  for  structuring  and  forming  teams 

2.  Operating  rules  for  teams 
Subpractices 

1 .  Establish  and  maintain  empowerment  mechanisms  to  enable  timely 
decision  making. 

In  a  successful  teaming  environment,  clear  channels  of  responsibility  and  authority  are 
established  by  documenting  and  deploying  organizational  guidelines  that  clearly  define 
the  empowerment  of  teams. 

2.  Establish  and  maintain  rules  and  guidelines  for  structuring  and  forming 
teams. 

i  Organizational  process  assets  can  help  the  project  to  structure  and  Implement  teams. 

I  Such  assets  can  Include  the  following: 

:•  Team  structure  guidelines 
I  •  Team  formation  guidelines 
I  •  Team  authority  and  responsibility  guidelines 

I  •  Guidelines  for  establishing  lines  of  communication,  authority,  and  escalation 
[  •  Team  leader  selection  criteria 

3.  Define  the  expectations,  rules,  and  guidelines  that  guide  how  teams 
work  collectively. 

f. - 

I  These  rules  and  guidelines  establish  organizational  practices  for  consistency  across 
;  teams  and  can  Include  the  following: 

i  •  How  Interfaces  among  teams  are  established  and  maintained 
i  •  How  assignments  are  accepted  and  transferred 
I  •  How  resources  and  Inputs  are  accessed 
I  •  How  work  gets  done 
;  •  Who  checks,  reviews,  and  approves  work 
;  •  How  work  Is  approved 
I  •  How  work  Is  delivered  and  communicated 
I  •  Who  reports  to  whom 

I  •  What  the  reporting  requirements  (e.g.,  cost,  schedule,  performance  status),  measures, 

I  and  methods  are 

I  •  Which  progress  reporting  measures  and  methods  are  used 
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ORGANIZATIONAL  PROCESS  FOCUS 

A  Process  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Organizational  Process  Focus  (OPF)  is  to  plan,  implement, 
and  deploy  organizational  process  improvements  based  on  a  thorough 
understanding  of  current  strengths  and  weaknesses  of  the  organization’s 
processes  and  process  assets. 


Introductory  Notes 


The  organization’s  processes  include  all  processes  used  by  the 
organization  and  its  projects.  Candidate  improvements  to  the  organization’s 
processes  and  process  assets  are  obtained  from  various  sources,  including 
the  measurement  of  processes,  lessons  learned  in  implementing 
processes,  results  of  process  appraisals,  results  of  product  and  service 
evaluation  activities,  results  of  customer  satisfaction  evaluations,  results  of 
benchmarking  against  other  organizations’  processes,  and 
recommendations  from  other  improvement  initiatives  in  the  organization. 

Process  improvement  occurs  in  the  context  of  the  organization’s  needs  and 
is  used  to  address  the  organization’s  objectives.  The  organization 
encourages  participation  in  process  improvement  activities  by  those  who 
perform  the  process.  The  responsibility  for  facilitating  and  managing  the 
organization’s  process  improvement  activities,  including  coordinating  the 
participation  of  others,  is  typically  assigned  to  a  process  group.  The 
organization  provides  the  long-term  commitment  and  resources  required  to 
sponsor  this  group  and  to  ensure  the  effective  and  timely  deployment  of 
improvements. 

Careful  planning  is  required  to  ensure  that  process  improvement  efforts 
across  the  organization  are  adequately  managed  and  implemented.  Results 
of  the  organization’s  process  improvement  planning  are  documented  in  a 
process  improvement  plan. 

The  “organization’s  process  improvement  plan”  addresses  appraisal 
planning,  process  action  planning,  pilot  planning,  and  deployment  planning. 
Appraisal  plans  describe  the  appraisal  timeline  and  schedule,  the  scope  of 
the  appraisal,  resources  required  to  perform  the  appraisal,  the  reference 
model  against  which  the  appraisal  will  be  performed,  and  logistics  for  the 
appraisal. 

Process  action  plans  usually  result  from  appraisals  and  document  how 
improvements  targeting  weaknesses  uncovered  by  an  appraisal  will  be 
implemented.  Sometimes  the  improvement  described  in  the  process  action 
plan  should  be  tested  on  a  small  group  before  deploying  it  across  the 
organization.  In  these  cases,  a  pilot  plan  is  generated. 


Organizational  Process  Focus  (OPF) 


203 


CMMI  for  Development,  Version  1.3 


When  the  improvement  is  to  be  deployed,  a  deployment  plan  is  created. 
This  plan  describes  when  and  how  the  improvement  will  be  deployed 
across  the  organization. 

Organizational  process  assets  are  used  to  describe,  implement,  and 
improve  the  organization’s  processes.  (See  the  definition  of  “organizational 
process  assets”  in  the  glossary.) 


Related  Process  Areas 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets. 

Specific  Goal  and  Practice  Summary 

SG  1  Determine  Process  Improvement  Opportunities 

SP  1.1  Establish  Organizational  Process  Needs 
SP  1 .2  Appraise  the  Organization’s  Processes 
SP  1 .3  Identify  the  Organization’s  Process  Improvements 
SG  2  Plan  and  Implement  Process  Actions 

SP  2.1  Establish  Process  Action  Plans 

SP  2.2  Implement  Process  Action  Plans 

SG  3  Deploy  Organizational  Process  Assets  and  Incorporate  Experiences 
SP  3.1  Deploy  Organizational  Process  Assets 

SP  3.2  Deploy  Standard  Processes 

SP  3.3  Monitor  the  Implementation 

SP  3.4  Incorporate  Experiences  into  Organizational  Process  Assets 

Specific  Practices  by  Goal 


SG  1  Determine  Process  Improvement  Opportunities 

Strengths,  weaknesses,  and  improvement  opportunities  for  the  organization’s 
processes  are  identified  periodicaiiy  and  as  needed. 

Strengths,  weaknesses,  and  improvement  opportunities  can  be  determined 
relative  to  a  process  standard  or  model  such  as  a  CMMI  model  or  ISO 
standard.  Process  improvements  should  be  selected  to  address  the 
organization’s  needs. 

Process  improvement  opportunities  can  arise  as  a  result  of  changing 
business  objectives,  legal  and  regulatory  requirements,  and  results  of 
benchmarking  studies. 

SP  1.1  Establish  Organizational  Process  Needs 

Estabiish  and  maintain  the  description  of  process  needs  and 
objectives  for  the  organization. 

The  organization’s  processes  operate  in  a  business  context  that  should  be 
understood.  The  organization’s  business  objectives,  needs,  and  constraints 
determine  the  needs  and  objectives  for  the  organization’s  processes. 
Typically,  issues  related  to  customer  satisfaction,  finance,  technology, 
quality,  human  resources,  and  marketing  are  important  process 
considerations. 
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The  organization’s  process  needs  and  objectives  cover  aspects  that  include  the  following: 

•  Characteristics  of  processes 

•  Process  performance  objectives,  such  as  time-to-market  and  delivered  quality 

•  Process  effectiveness 


Example  Work  Products 

1 .  The  organization’s  process  needs  and  objectives 
Subpractices 

1 .  Identify  policies,  standards,  and  business  objectives  that  are  applicable 
to  the  organization’s  processes. 

i  Examples  of  standards  include  the  following: 

;  •  ISO/IEC  12207:2008  Systems  and  Software  Engineering  -  Software  Life  Cycle 
i  Processes  [ISO  2008a] 

;  •  ISO/IEC  15288:2008  Systems  and  Software  Engineering  -  System  Life  Cycle 
i  Processes  [ISO  2008b] 

;  •  ISO/IEC  27001 :2005  Information  technology  -  Security  techniques  -  Information 
i  Security  Management  Systems  -  Requirements  [ISO/IEC  2005] 

I  •  ISO/IEC  14764:2006  Software  Engineering  -  Software  Life  Cycle  Processes  - 
;  Maintenance  [ISO  2006b] 

I  •  ISO/IEC  20000  Information  Technology  -  Service  Management  [ISO  2005b] 

;  •  Assurance  Focus  for  CMMI  [DHS  2009] 

;  •  NDIA  Engineering  for  System  Assurance  Guidebook  [NDIA  2008] 

I  •  Resiliency  Management  Model  [SEI  2010c] 

2.  Examine  relevant  process  standards  and  models  for  best  practices. 

3.  Determine  the  organization’s  process  performance  objectives. 

Process  performance  objectives  can  be  expressed  in  quantitative  or  qualitative  terms. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  measurement  objectives. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  establishing  quality  and  process  performance 
objectives. 

f. - 

I  Examples  of  process  performance  objectives  include  the  following: 

I  •  Achieve  a  customer  satisfaction  rating  of  a  certain  value 
I  •  Ensure  product  reliability  is  at  least  a  certain  percentage 
I  •  Reduce  defect  insertion  rate  by  a  certain  percentage 
I  •  Achieve  a  certain  cycle  time  for  a  given  activity 
I  •  Improve  productivity  by  a  given  percentage 
:  •  Simplify  the  requirements  approval  workflow 
i  •  Improve  quality  of  products  delivered  to  customer 
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4.  Define  essential  characteristics  of  the  organization’s  processes. 

Essential  characteristics  of  the  organization’s  processes  are  determined  based  on  the 
following: 

•  Processes  currently  being  used  In  the  organization 

•  Standards  Imposed  by  the  organization 

•  Standards  commonly  Imposed  by  customers  of  the  organization 

I  Examples  of  process  characteristics  Include  the  following: 

:  •  Level  of  detail 
i  •  Process  notation 
[  •  Granularity 

5.  Document  the  organization’s  process  needs  and  objectives. 

6.  Revise  the  organization’s  process  needs  and  objectives  as  needed. 

SP  1.2  Appraise  the  Organization’s  Processes 

Appraise  the  organization’s  processes  periodicaiiy  and  as  needed 
to  maintain  an  understanding  of  their  strengths  and  weaknesses. 

f - ... - - - - - 

I  Process  appraisals  can  be  performed  for  the  following  reasons: 

I  •  To  Identify  processes  to  be  Improved 

;  •  To  confirm  progress  and  make  the  benefits  of  process  Improvement  visible 

;  •  To  satisfy  the  needs  of  a  customer-supplier  relationship 

i  •  To  motivate  and  facilitate  buy-ln 


The  buy-in  gained  during  a  process  appraisal  can  be  eroded  significantly  if 
it  is  not  followed  by  an  appraisal  based  action  plan. 

Example  Work  Products 

1 .  Plans  for  the  organization’s  process  appraisals 

2.  Appraisal  findings  that  address  strengths  and  weaknesses  of  the 
organization’s  processes 

3.  Improvement  recommendations  for  the  organization’s  processes 

Subpractices 

1 .  Obtain  sponsorship  of  the  process  appraisal  from  senior  management. 

Senior  management  sponsorship  includes  the  commitment  to  have  the  organization’s 
managers  and  staff  participate  in  the  process  appraisal  and  to  provide  resources  and 
funding  to  analyze  and  communicate  findings  of  the  appraisal. 

2.  Define  the  scope  of  the  process  appraisal. 

Process  appraisals  can  be  performed  on  the  entire  organization  or  can  be  performed 
on  a  smaller  part  of  an  organization  such  as  a  single  project  or  business  area. 

The  scope  of  the  process  appraisal  addresses  the  following: 


206 


Organizational  Process  Focus  (OPF) 


CMMI  for  Development,  Version  1.3 


•  Definition  of  the  organization  (e.g.,  sites,  business  areas)  to  be  covered  by  the 
appraisai 

•  Identification  of  the  project  and  support  functions  that  wiii  represent  the  organization  in 
the  appraisai 

•  Processes  to  be  appraised 

3.  Determine  the  method  and  criteria  to  be  used  for  the  process 
appraisal. 

Process  appraisals  can  occur  in  many  forms.  They  should  address  the  needs  and 
objectives  of  the  organization,  which  can  change  over  time.  For  example,  the  appraisal 
can  be  based  on  a  process  model,  such  as  a  CMMI  model,  or  on  a  national  or 
international  standard,  such  as  ISO  9001  [ISO  2008c].  Appraisals  can  also  be  based 
on  a  benchmark  comparison  with  other  organizations  in  which  practices  that  can 
contribute  to  improved  organizational  performance  are  identified.  The  characteristics  of 
the  appraisal  method  may  vary,  including  time  and  effort,  makeup  of  the  appraisal 
team,  and  the  method  and  depth  of  investigation. 

4.  Plan,  schedule,  and  prepare  for  the  process  appraisal. 

5.  Conduct  the  process  appraisal. 

6.  Document  and  deliver  the  appraisal’s  activities  and  findings. 

SP  1.3  Identify  the  Organization’s  Process  Improvements 

Identify  improvements  to  the  organization’s  processes  and 
process  assets. 


Example  Work  Products 

1 .  Analysis  of  candidate  process  improvements 

2.  Identification  of  improvements  for  the  organization’s  processes 
Subpractices 

1 .  Determine  candidate  process  improvements. 

:  Candidate  process  improvements  are  typically  determined  by  doing  the  following: 

i  •  Measuring  processes  and  analyzing  measurement  results 
i  •  Reviewing  processes  for  effectiveness  and  suitability 
i  •  Assessing  customer  satisfaction 

i  •  Reviewing  lessons  learned  from  tailoring  the  organization's  set  of  standard  processes 
;  •  Reviewing  lessons  learned  from  implementing  processes 

;  •  Reviewing  process  improvement  proposals  submitted  by  the  organization's  managers, 
i  staff,  and  other  relevant  stakeholders 

i  •  Soliciting  inputs  on  process  improvements  from  senior  management  and  other  leaders 
;  in  the  organization 

I  •  Examining  results  of  process  appraisals  and  other  process  related  reviews 
I  •  Reviewing  results  of  other  organizational  improvement  initiatives 


2.  Prioritize  candidate  process  improvements. 
Criteria  for  prioritization  are  as  follows: 
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•  Consider  the  estimated  cost  and  effort  to  impiement  the  process  improvements. 

•  Evaiuate  the  expected  improvement  against  the  organization's  improvement  objectives 
and  priorities. 

•  Determine  the  potentiai  barriers  to  the  process  improvements  and  deveiop  strategies 
for  overcoming  these  barriers. 

Examples  of  techniques  to  help  determine  and  prioritize  possible  improvements  to  be 

implemented  include  the  following: 

•  A  cost  benefit  analysis  that  compares  the  estimated  cost  and  effort  to  implement  the 
process  improvements  and  their  associated  benefits 

•  A  gap  analysis  that  compares  current  conditions  in  the  organization  with  optimal 
conditions 

•  Force  field  analysis  of  potential  improvements  to  identify  potential  barriers  and 
strategies  for  overcoming  those  barriers 

•  Cause-and-effect  analyses  to  provide  information  on  the  potential  effects  of  different 
improvements  that  can  then  be  compared 


3.  Identify  and  document  the  process  improvements  to  be  implemented. 

4.  Revise  the  list  of  planned  process  improvements  to  keep  it  current. 

SG  2  Plan  and  Implement  Process  Actions 

Process  actions  that  address  improvements  to  the  organization’s  processes 
and  process  assets  are  pianned  and  impiemented. 

The  successful  implementation  of  improvements  requires  participation  in 
process  action  planning  and  implementation  by  process  owners,  those  who 
perform  the  process,  and  support  organizations. 

SP  2.1  Establish  Process  Action  Plans 

Estabiish  and  maintain  process  action  pians  to  address 
improvements  to  the  organization’s  processes  and  process  assets. 

i  Establishing  and  maintaining  process  action  plans  typically  involves  the  following  roles: 

i  •  Management  steering  committees  that  set  strategies  and  oversee  process  improvement 
I  activities 

;  •  Process  groups  that  facilitate  and  manage  process  improvement  activities 
i  •  Process  action  teams  that  define  and  implement  process  actions 
;  •  Process  owners  that  manage  deployment 
i  •  Practitioners  that  perform  the  process 


Stakeholder  involvement  helps  to  obtain  buy-in  on  process  improvements 
and  increases  the  likelihood  of  effective  deployment. 

Process  action  plans  are  detailed  implementation  plans.  These  plans  differ 
from  the  organization’s  process  improvement  plan  by  targeting 
improvements  that  were  defined  to  address  weaknesses  and  that  were 
usually  uncovered  by  appraisals. 
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Example  Work  Products 

1 .  The  organization’s  approved  process  action  plans 
Subpractices 

1 .  Identify  strategies,  approaches,  and  actions  to  address  identified 
process  improvements. 

New,  unproven,  and  major  changes  are  piloted  before  they  are  incorporated  into 
normal  use. 

2.  Establish  process  action  teams  to  implement  actions. 

The  teams  and  people  performing  the  process  Improvement  actions  are  called 
‘‘process  action  teams.”  Process  action  teams  typically  Include  process  owners  and 
those  who  perform  the  process. 

3.  Document  process  action  plans. 

;  Process  action  plans  typically  cover  the  following: 

I  •  Process  Improvement  Infrastructure 

I  •  Process  Improvement  objectives 

I  •  Process  Improvements  to  be  addressed 

I  •  Procedures  for  planning  and  tracking  process  actions 

I  •  Strategies  for  piloting  and  Implementing  process  actions 

I  •  Responsibility  and  authority  for  Implementing  process  actions 

:  •  Resources,  schedules,  and  assignments  for  Implementing  process  actions 

i  •  Methods  for  determining  the  effectiveness  of  process  actions 

[  •  Risks  associated  with  process  action  plans 

4.  Review  and  negotiate  process  action  plans  with  relevant  stakeholders. 

5.  Revise  process  action  plans  as  necessary. 

SP  2.2  Implement  Process  Action  Plans 

Implement  process  action  plans. 

Example  Work  Products 

1 .  Commitments  among  process  action  teams 

2.  Status  and  results  of  implementing  process  action  plans 

3.  Plans  for  pilots 
Subpractices 

1 .  Make  process  action  plans  readily  available  to  relevant  stakeholders. 

2.  Negotiate  and  document  commitments  among  process  action  teams 
and  revise  their  process  action  plans  as  necessary. 

3.  Track  progress  and  commitments  against  process  action  plans. 

4.  Conduct  joint  reviews  with  process  action  teams  and  relevant 
stakeholders  to  monitor  the  progress  and  results  of  process  actions. 
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5.  Plan  pilots  needed  to  test  selected  process  improvements. 

6.  Review  the  activities  and  work  products  of  process  action  teams. 

7.  Identify,  document,  and  track  to  closure  issues  encountered  when 
implementing  process  action  plans. 

8.  Ensure  that  results  of  implementing  process  action  plans  satisfy  the 
organization’s  process  improvement  objectives. 

SG  3 _ Deploy  Organizational  Process  Assets  and  Incorporate  Experiences _ 

Organizational  process  assets  are  deployed  across  the  organization  and 
process  related  experiences  are  incorporated  into  organizational  process 
assets. 

The  specific  practices  under  this  specific  goal  describe  ongoing  activities. 
New  opportunities  to  benefit  from  organizational  process  assets  and 
changes  to  them  can  arise  throughout  the  life  of  each  project.  Deployment 
of  standard  processes  and  other  organizational  process  assets  should  be 
continually  supported  in  the  organization,  particularly  for  new  projects  at 
startup. 

SP  3.1  Deploy  Organizational  Process  Assets 

Deploy  organizational  process  assets  across  the  organization. 

Deploying  organizational  process  assets  or  changes  to  them  should  be 
performed  in  an  orderly  manner.  Some  organizational  process  assets  or 
changes  to  them  may  not  be  appropriate  for  use  in  some  parts  of  the 
organization  (e.g.,  because  of  stakeholder  requirements  or  the  current 
lifecycle  phase  being  implemented).  It  is  therefore  important  that  those  who 
are  or  will  be  executing  the  process,  as  well  as  other  organization  functions 
(e.g.,  training,  quality  assurance),  be  involved  in  deployment  as  necessary. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets. 

Example  Work  Products 

1 .  Plans  for  deploying  organizational  process  assets  and  changes  to 
them  across  the  organization 

2.  Training  materials  for  deploying  organizational  process  assets  and 
changes  to  them 

3.  Documentation  of  changes  to  organizational  process  assets 

4.  Support  materials  for  deploying  organizational  process  assets  and 
changes  to  them 

Subpractices 

1 .  Deploy  organizational  process  assets  across  the  organization. 
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I  Typical  activities  performed  as  a  part  of  the  deployment  of  process  assets  include  the 
i  following: 

I  •  Identifying  organizational  process  assets  that  should  be  adopted  by  those  who  perform 
I  the  process 

;  •  Determining  how  organizational  process  assets  are  made  available  (e.g.,  via  a 
I  website) 

I  •  Identifying  how  changes  to  organizational  process  assets  are  communicated 

I  •  Identifying  resources  (e.g.,  methods,  tools)  needed  to  support  the  use  of  organizational 

I  process  assets 

I  •  Planning  the  deployment 
I  •  Assisting  those  who  use  organizational  process  assets 
•  Ensuring_  that  training  is  available  for  those  who  use  organizational  process  assets 


Refer  to  the  Organizational  Training  process  area  for  more  information 
about  establishing  an  organizational  training  capability. 

2.  Document  changes  to  organizational  process  assets. 

Documenting  changes  to  organizational  process  assets  serves  two  main  purposes: 

•  To  enable  the  communication  of  changes 

•  To  understand  the  relationship  of  changes  in  the  organizational  process  assets  to 
changes  in  process  performance  and  results 

3.  Deploy  changes  that  were  made  to  organizational  process  assets 
across  the  organization. 

;  Typical  activities  performed  as  a  part  of  deploying  changes  include  the  following: 

;  •  Determining  which  changes  are  appropriate  for  those  who  perform  the  process 
I  •  Planning  the  deployment 

I  •  Arranging  for  the  support  needed  for  the  successful  transition  of  changes 

4.  Provide  guidance  and  consultation  on  the  use  of  organizational 
process  assets. 

SP  3.2  Deploy  Standard  Processes 

Deploy  the  organization’s  set  of  standard  processes  to  projects  at 
their  startup  and  deploy  changes  to  them  as  appropriate 
throughout  the  life  of  each  project. 

It  is  important  that  new  projects  use  proven  and  effective  processes  to 
perform  critical  early  activities  (e.g.,  project  planning,  receiving 
requirements,  obtaining  resources). 

Projects  should  also  periodically  update  their  defined  processes  to 
incorporate  the  latest  changes  made  to  the  organization’s  set  of  standard 
processes  when  it  will  benefit  them.  This  periodic  update  helps  to  ensure 
that  all  project  activities  derive  the  full  benefit  of  what  other  projects  have 
learned. 
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Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  standard  processes  and  establishing  tailoring 
criteria  and  guidelines. 

Example  Work  Products 

1 .  The  organization’s  list  of  projects  and  the  status  of  process  deployment 
on  each  (i.e.,  existing  and  planned  projects) 

2.  Guidelines  for  deploying  the  organization’s  set  of  standard  processes 
on  new  projects 

3.  Records  of  tailoring  and  implementing  the  organization’s  set  of 
standard  processes 

Subpractices 

1 .  Identify  projects  in  the  organization  that  are  starting  up. 

2.  Identify  active  projects  that  would  benefit  from  implementing  the 
organization’s  current  set  of  standard  processes. 

3.  Establish  plans  to  implement  the  organization’s  current  set  of  standard 
processes  on  the  identified  projects. 

4.  Assist  projects  in  tailoring  the  organization’s  set  of  standard  processes 
to  meet  their  needs. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process. 

5.  Maintain  records  of  tailoring  and  implementing  processes  on  the 
identified  projects. 

6.  Ensure  that  the  defined  processes  resulting  from  process  tailoring  are 
incorporated  into  plans  for  process  compliance  audits. 

Process  compliance  audits  are  objective  evaluations  of  project  activities  against  the 
project’s  defined  process. 

7.  As  the  organization’s  set  of  standard  processes  is  updated,  identify 
which  projects  should  implement  the  changes. 

SP  3.3  Monitor  the  Implementation 

Monitor  the  implementation  of  the  organization’s  set  of  standard 
processes  and  use  of  process  assets  on  all  projects. 

By  monitoring  implementation,  the  organization  ensures  that  the 
organization’s  set  of  standard  processes  and  other  process  assets  are 
appropriately  deployed  to  all  projects.  Monitoring  implementation  also  helps 
the  organization  to  develop  an  understanding  of  the  organizational  process 
assets  being  used  and  where  they  are  used  in  the  organization.  Monitoring 
also  helps  to  establish  a  broader  context  for  interpreting  and  using  process 
and  product  measures,  lessons  learned,  and  improvement  information 
obtained  from  projects. 

Example  Work  Products 

1 .  Results  of  monitoring  process  implementation  on  projects 
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2.  Status  and  results  of  process  compliance  audits 

3.  Results  of  reviewing  selected  process  artifacts  created  as  part  of 
process  tailoring  and  implementation 

Subpractices 

1 .  Monitor  the  projects’  use  of  organizational  process  assets  and  changes 
to  them. 

2.  Review  selected  process  artifacts  created  during  the  life  of  each 
project. 

Reviewing  selected  process  artifacts  created  during  the  life  of  a  project  ensures  that  all 
projects  are  making  appropriate  use  of  the  organization’s  set  of  standard  processes. 

3.  Review  results  of  process  compliance  audits  to  determine  how  well  the 
organization’s  set  of  standard  processes  has  been  deployed. 

Refer  to  the  Process  and  Product  Quality  Assurance  process  area  for 
more  information  about  objectively  evaluating  processes. 

4.  Identify,  document,  and  track  to  closure  issues  related  to  implementing 
the  organization’s  set  of  standard  processes. 

SP  3.4  Incorporate  Experiences  into  Organizational  Process  Assets 

Incorporate  process  related  experiences  derived  from  planning  and 
performing  the  process  into  organizational  process  assets. 


Example  Work  Products 

1 .  Process  improvement  proposals 

2.  Process  lessons  learned 

3.  Measurements  of  organizational  process  assets 

4.  Improvement  recommendations  for  organizational  process  assets 

5.  Records  of  the  organization’s  process  improvement  activities 

6.  Information  on  organizational  process  assets  and  improvements  to 
them 

Subpractices 

1 .  Conduct  periodic  reviews  of  the  effectiveness  and  suitability  of  the 
organization’s  set  of  standard  processes  and  related  organizational 
process  assets  relative  to  the  process  needs  and  objectives  derived 
from  the  organization’s  business  objectives. 

2.  Obtain  feedback  about  the  use  of  organizational  process  assets. 

3.  Derive  lessons  learned  from  defining,  piloting,  implementing,  and 
deploying  organizational  process  assets. 

4.  Make  lessons  learned  available  to  people  in  the  organization  as 
appropriate. 

Actions  may  be  necessary  to  ensure  that  lessons  learned  are  used  appropriately. 
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I  Examples  of  the  inappropriate  use  of  lessons  learned  include  the  following: 

I  •  Evaluating  the  performance  of  people 
•  Judging  process  performance  or  results 


Examples  of  ways  to  prevent  the  inappropriate  use  of  lessons  learned  include  the 
following: 

•  Controlling  access  to  lessons  learned 

•  Educating  people  about  the  appropriate  use  of  lessons  learned 


5.  Analyze  measurement  data  obtained  from  the  use  of  the  organization’s 
common  set  of  measures. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  analyzing  measurement  data. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  the  organization’s  measurement 
repository. 

6.  Appraise  processes,  methods,  and  tools  in  use  in  the  organization  and 
develop  recommendations  for  improving  organizational  process  assets. 

:  This  appraisal  typically  includes  the  following: 

i  •  Determining  which  processes,  methods,  and  tools  are  of  potential  use  to  other  parts  of 
;  the  organization 

i  •  Appraising  the  quality  and  effectiveness  of  organizational  process  assets 
i  •  Identifying  candidate  improvements  to  organizational  process  assets 

;  •  Determining  compliance  with  the  organization's  set  of  standard  processes  and  tailoring 
i  guidelines 


7.  Make  the  best  of  the  organization’s  processes,  methods,  and  tools 
available  to  people  in  the  organization  as  appropriate. 

8.  Manage  process  improvement  proposals. 

Process  improvement  proposals  can  address  both  process  and  technology 
improvements. 

;  The  activities  for  managing  process  improvement  proposals  typically  include  the 
i  following: 

;  •  Soliciting  process  improvement  proposals 
;  •  Collecting  process  improvement  proposals 
i  •  Reviewing  process  improvement  proposals 
i  •  Selecting  the  process  improvement  proposals  to  be  implemented 
I  •  Tracking  the  implementation  of  process  improvement  proposals 


Process  improvement  proposals  are  documented  as  process  change  requests  or 
problem  reports  as  appropriate. 
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Some  process  improvement  proposals  can  be  incorporated  into  the  organization’s 
process  action  plans. 

9.  Establish  and  maintain  records  of  the  organization’s  process 
improvement  activities. 
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ORGANIZATIONAL  PERFORMANCE  MANAGEMENT 

A  Process  Management  Process  Area  at  Maturity  Level  5 


Purpose 


The  purpose  of  Organizational  Performance  Management  (0PM)  is  to 
proactively  manage  the  organization’s  performance  to  meet  its  business 
objectives. 


Introductory  Notes 


The  Organizational  Performance  Management  process  area  enables  the 
organization  to  manage  organizational  performance  by  iteratively  analyzing 
aggregated  project  data,  identifying  gaps  in  performance  against  the 
business  objectives,  and  selecting  and  deploying  improvements  to  close  the 
gaps. 

In  this  process  area,  the  term  “improvement”  includes  all  incremental  and 
innovative  process  and  technology  improvements,  including  those 
improvements  made  to  project  work  environments.  “Improvement”  refers  to 
all  ideas  that  would  change  the  organization’s  processes,  technologies,  and 
performance  to  better  meet  the  organization’s  business  objectives  and 
associated  quality  and  process  performance  objectives. 

Business  objectives  that  this  process  area  might  address  include  the 
following: 

•  Improved  product  quality  (e.g.,  functionality,  quality  attributes) 

•  Increased  productivity 

•  Increased  process  efficiency  and  effectiveness 

•  Increased  consistency  in  meeting  budget  and  schedule 

•  Decreased  cycle  time 

•  Greater  customer  and  end-user  satisfaction 

•  Shorter  development  or  production  time  to  change  functionality,  add 
new  features,  or  adapt  to  new  technologies 

•  Improved  performance  of  a  supply  chain  involving  multiple  suppliers 

•  Improved  use  of  resources  across  the  organization 

The  organization  analyzes  product  and  process  performance  data  from  the 
projects  to  determine  if  it  is  capable  of  meeting  the  quality  and  process 
performance  objectives.  Process  performance  baselines  and  process 
performance  models,  developed  using  Organizational  Process  Performance 
processes,  are  used  as  part  of  the  analysis.  Causal  Analysis  and 
Resolution  processes  can  also  be  used  to  identify  potential  areas  of 
improvement  or  specific  improvement  proposals. 
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The  organization  identifies  and  proactively  solicits  incremental  and 
innovative  improvements  from  within  the  organization  and  from  external 
sources  such  as  academia,  competitive  intelligence,  and  successful 
improvements  implemented  elsewhere. 

Realization  of  the  improvements  and  their  effects  on  the  quality  and 
process  performance  objectives  depends  on  being  able  to  effectively 
identify,  evaluate,  implement,  and  deploy  improvements  to  the 
organization’s  processes  and  technologies. 

Realization  of  the  improvements  and  beneficial  effects  also  depends  on 
engaging  the  workforce  in  identifying  and  evaluating  possible  improvements 
and  maintaining  a  focus  on  long-term  planning  that  includes  the 
identification  of  innovations. 

Improvement  proposals  are  evaluated  and  validated  for  their  effectiveness 
in  the  target  environment.  Based  on  this  evaluation,  improvements  are 
prioritized  and  selected  for  deployment  to  new  and  ongoing  projects. 
Deployment  is  managed  in  accordance  with  the  deployment  plan  and 
performance  data  are  analyzed  using  statistical  and  other  quantitative 
techniques  to  determine  the  effects  of  the  improvement  on  quality  and 
process  performance  objectives. 

This  improvement  cycle  continually  optimizes  organizational  processes 
based  on  quality  and  process  performance  objectives.  Business  objectives 
are  periodically  reviewed  to  ensure  they  are  current  and  quality  and  process 
performance  objectives  are  updated  as  appropriate. 

The  Organizational  Process  Focus  process  area  includes  no  assumptions 
about  the  quantitative  basis  for  identifying  improvements,  nor  their  expected 
results.  This  process  area  extends  the  Organizational  Process  Focus 
practices  by  focusing  on  process  improvement  based  on  a  quantitative 
understanding  of  the  organization’s  set  of  standard  processes  and 
technologies  and  their  expected  quality  and  process  performance. 

The  specific  practices  of  this  process  area  apply  to  organizations  whose 
projects  are  quantitatively  managed.  Use  of  the  specific  practices  of  this 
process  area  can  add  value  in  other  situations,  but  the  results  may  not 
provide  the  same  degree  of  impact  to  the  organization’s  quality  and  process 
performance  objectives. 


Related  Process  Areas 


Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  identifying  causes  of  selected  outcomes  and  taking  action 
to  improve  process  performance. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  analyzing  possible  decisions  using  a  formal  evaluation 
process  that  evaluates  identified  alternatives  against  established  criteria. 
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Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  aligning  measurement  and  analysis  activities  and  providing 
measurement  results. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  planning,  implementing,  and  deploying  organizational 
process  improvements  based  on  a  thorough  understanding  of  current 
strengths  and  weaknesses  of  the  organization’s  processes  and  process 
assets. 

Refer  to  the  Organizational  Process  Performance  process  area  for  more 
information  about  establishing  quality  and  process  performance  objectives 
and  establishing  process  performance  baselines  and  models. 

Refer  to  the  Organizational  Training  process  area  for  more  information 
about  providing  training. 

Specific  Goai  and  Practice  Summary 

SG  1  Manage  Business  Performance 

SP1.1  Maintain  Business  Objectives 
SP  1 .2  Analyze  Process  Performance  Data 
SP  1 .3  Identify  Potential  Areas  for  Improvement 

SG  2  Select  Improvements 

SP  2.1  Elicit  Suggested  Improvements 
SP  2.2  Analyze  Suggested  Improvements 

SP  2.3  Validate  Improvements 

SP  2.4  Select  and  Implement  Improvements  tor  Deployment 
SG  3  Deploy  Improvements 

SP  3.1  Plan  the  Deployment 

SP  3.2  Manage  the  Deployment 

SP  3.3  Evaluate  Improvement  Effects 

Specific  Practices  by  Goai 


SG  1  Manage  Business  Performance 

The  organization’s  business  performance  is  managed  using  statisticai  and 
other  quantitative  techniques  to  understand  process  performance  shortfaiis, 
and  to  identify  areas  for  process  improvement 

Managing  business  performance  requires  the  foiiowing: 

•  Maintaining  the  organization’s  business  objectives 

•  Understanding  the  organization’s  abiiity  to  meet  the  business  objectives 

•  Continuaiiy  improving  processes  reiated  to  achieving  the  business 
objectives 

The  organization  uses  defined  process  performance  baseiines  to  determine 
if  the  current  and  projected  organizationai  business  objectives  are  being 
met.  Shortfaiis  in  process  performance  are  identified  and  anaiyzed  to 
determine  potentiai  areas  for  process  improvement. 

Refer  to  the  Organizational  Process  Performance  process  area  for  more 
information  about  establishing  performance  baselines  and  models. 


Organizational  Performance  Management  (0PM) 


219 


CMMI  for  Development,  Version  1.3 


As  the  organization  improves  its  process  performance  or  as  business 
strategies  change,  new  business  objectives  are  identified  and  associated 
quality  and  process  performance  objectives  are  derived. 

Specific  goal  2  addresses  eliciting  and  analyzing  improvement  suggestions 
that  address  shortfalls  in  achieving  quality  and  process  performance 
objectives. 

SP  1.1  Maintain  Business  Objectives 

Maintain  business  objectives  based  on  an  understanding  of 
business  strategies  and  actuai  performance  resuits. 

Organizational  performance  data,  characterized  by  process  performance 
baselines,  are  used  to  evaluate  whether  business  objectives  are  realistic 
and  aligned  with  business  strategies.  After  business  objectives  have  been 
revised  and  prioritized  by  senior  management,  quality  and  process 
performance  objectives  may  need  to  be  created  or  maintained  and  re¬ 
communicated. 

Example  Work  Products 

1.  Revised  business  objectives 

2.  Revised  quality  and  process  performance  objectives 

3.  Senior  management  approval  of  revised  business  objectives  and 
quality  and  process  performance  objectives 

4.  Communication  of  all  revised  objectives 

5.  Updated  process  performance  measures 
Subpractices 

1 .  Evaluate  business  objectives  periodically  to  ensure  they  are  aligned 
with  business  strategies. 

Senior  management  is  responsible  for  understanding  the  marketplace,  establishing 
business  strategies,  and  establishing  business  objectives. 

Because  business  strategies  and  organizational  performance  evolve,  business 
objectives  should  be  reviewed  periodically  to  determine  whether  they  should  be 
updated.  For  example,  a  business  objective  might  be  retired  when  process 
performance  data  show  that  the  business  objective  is  being  met  consistently  over  time 
or  when  the  associated  business  strategy  has  changed. 

2.  Compare  business  objectives  with  actual  process  performance  results 
to  ensure  they  are  realistic. 

Business  objectives  can  set  the  bar  too  high  to  motivate  real  improvement.  Using 
process  performance  baselines  helps  balance  desires  and  reality. 

If  process  performance  baselines  are  unavailable,  sampling  techniques  can  be  used  to 
develop  a  quantitative  basis  for  comparison  in  a  short  period  of  time. 

3.  Prioritize  business  objectives  based  on  documented  criteria,  such  as 
the  ability  to  win  new  business,  retain  existing  clients,  or  accomplish 
other  key  business  strategies. 
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4.  Maintain  quaiity  and  process  performance  objectives  to  address 
changes  in  business  objectives. 

Business  objectives  and  quaiity  and  process  performance  objectives  wiii  typicaiiy 
evoive  over  time.  As  existing  objectives  are  achieved,  they  wiii  be  monitored  to  ensure 
they  continue  to  be  met,  whiie  new  business  objectives  and  associated  quaiity  and 
process  performance  objectives  are  identified  and  managed. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  establishing  quality  and  process  performance 
objectives. 

5.  Revise  process  performance  measures  to  aiign  with  quaiity  and 
process  performance  objectives. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  establishing  process  performance  measures. 

SP  1 .2  Analyze  Process  Performance  Data 

Analyze  process  performance  data  to  determine  the  organization’s 
ability  to  meet  identified  business  objectives. 

The  data  that  resuit  from  appiying  the  process  performance  measures, 
which  are  defined  using  Organizationai  Process  Performance  processes, 
are  anaiyzed  to  create  process  performance  baseiines  that  heip  in 
understanding  the  current  capabiiity  of  the  organization.  Comparing  process 
performance  baseiines  to  quaiity  and  process  performance  objectives  heips 
the  organization  to  determine  its  abiiity  to  meet  business  objectives.  This 
data  typicaiiy  are  coiiected  from  project  ievei  process  performance  data  to 
enabie  organizationai  anaiysis. 

Example  Work  Products 

1 .  Anaiysis  of  current  capabiiity  vs.  business  objectives 

2.  Process  performance  shortfaiis 

3.  Risks  associated  with  meeting  business  objectives 

Subpractices 

1 .  Periodicaiiy  compare  quaiity  and  process  performance  objectives  to 
current  process  performance  baseiines  to  evaiuate  the  abiiity  of  the 
organization  to  meet  its  business  objectives. 

For  example,  if  cycle  time  is  a  critical  business  need,  many  different  cycle  time 
measures  may  be  collected  by  the  organization.  Overall  cycle  time  performance  data 
should  be  compared  to  the  business  objectives  to  understand  if  expected  performance 
will  satisfy  business  objectives. 

2.  Identify  shortfalls  where  the  actual  process  performance  is  not 
satisfying  the  business  objectives. 

3.  Identify  and  analyze  risks  associated  with  not  meeting  business 
objectives. 
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4.  Report  results  of  the  process  performance  and  risk  analyses  to 
organizational  leadership. 

SP  1 .3  Identify  Potential  Areas  for  Improvement 

Identify  potential  areas  for  improvement  that  could  contribute  to 
meeting  business  objectives. 

Potential  areas  for  improvement  are  identified  through  a  proactive  analysis 
to  determine  areas  that  could  address  process  performance  shortfalls. 
Causal  Analysis  and  Resolution  processes  can  be  used  to  diagnose  and 
resolve  root  causes. 

The  output  from  this  activity  is  used  to  evaluate  and  prioritize  potential 
improvements,  and  can  result  in  either  incremental  or  innovative 
improvement  suggestions  as  described  in  specific  goal  2. 

Example  Work  Products 

1 .  Potential  areas  for  improvement 

Subpractices 

1 .  Identify  potential  improvement  areas  based  on  the  analysis  of  process 
performance  shortfalls. 

Performance  shortfalls  include  not  meeting  productivity,  cycle  time,  or  customer 
satisfaction  objectives.  Examples  of  areas  to  consider  for  improvement  include  product 
technology,  process  technology,  staffing  and  staff  development,  team  structures, 
supplier  selection  and  management,  and  other  organizational  infrastructures. 

2.  Document  the  rationale  for  the  potential  improvement  areas,  including 
references  to  applicable  business  objectives  and  process  performance 
data. 

3.  Document  anticipated  costs  and  benefits  associated  with  addressing 
potential  improvement  areas. 

4.  Communicate  the  set  of  potential  improvement  areas  for  further 
evaluation,  prioritization,  and  use. 

SG  2 _ Select  Improvements _ 

Improvements  are  proactively  identified,  evaluated  using  statistical  and  other 
quantitative  techniques,  and  selected  for  deployment  based  on  their 
contribution  to  meeting  quality  and  process  performance  objectives. 

Improvements  to  be  deployed  across  the  organization  are  selected  from 
improvement  suggestions  which  have  been  evaluated  for  effectiveness  in 
the  target  deployment  environment.  These  improvement  suggestions  are 
elicited  and  submitted  from  across  the  organization  to  address  the 
improvement  areas  identified  in  specific  goal  1 . 

Evaluations  of  improvement  suggestions  are  based  on  the  following: 

•  A  quantitative  understanding  of  the  organization’s  current  quality  and 
process  performance 


222 


Organizational  Performance  Management  (0PM) 


CMMI  for  Development,  Version  1.3 


•  Satisfaction  of  the  organization’s  quality  and  process  performance 
objectives 

•  Estimated  costs  and  impacts  of  developing  and  deploying  the 
improvements,  resources,  and  funding  available  for  deployment 

•  Estimated  benefits  in  quality  and  process  performance  resulting  from 
deploying  the  improvements 

SP  2.1  Elicit  Suggested  Improvements 

Elicit  and  categorize  suggested  improvements. 

This  practice  focuses  on  eliciting  suggested  improvements  and  includes 
categorizing  suggested  improvements  as  incremental  or  innovative. 

Incremental  improvements  generally  originate  with  those  who  do  the  work 
(i.e.,  users  of  the  process  or  technology).  Incremental  improvements  can  be 
simple  and  inexpensive  to  implement  and  deploy.  Incremental  improvement 
suggestions  are  analyzed,  but,  if  selected,  may  not  need  rigorous  validation 
or  piloting.  Innovative  improvements  such  as  new  or  redesigned  processes 
are  more  transformational  than  incremental  improvements. 

Innovative  improvements  often  arise  out  of  a  systematic  search  for 
solutions  to  particular  performance  issues  or  opportunities  to  improve 
performance.  They  are  identified  by  those  who  are  trained  and  experienced 
with  the  maturation  of  particular  technologies  or  whose  job  it  is  to  track  or 
directly  contribute  to  increased  performance. 

Innovations  can  be  found  externally  by  actively  monitoring  innovations  used 
in  other  organizations  or  documented  in  the  research  literature.  Innovations 
can  also  be  found  by  looking  internally  (e.g.,  by  examining  project  lessons 
learned).  Innovations  are  inspired  by  the  need  to  achieve  quality  and 
process  performance  objectives,  the  need  to  improve  performance 
baselines,  or  the  external  business  environment. 

I  Examples  of  incremental  Improvements  Include  the  following: 

:  •  Adding  an  Item  to  a  peer  review  checklist. 

I  •  Combining  the  technical  review  and  management  review  for  suppliers  Into  a  single 
i  review. 

;  •  Introducing  an  Incident  workaround. 

I  •  Substituting  a  new  component. 

I  •  Making  minor  updates  to  a  tool. 
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Examples  of  innovative  improvements  typically  include  additions  or  major  updates  to  the 
following: 

•  Computer  and  related  hardware  products 

•  Transformational  support  tools 

•  New  or  redesigned  workflows 

•  Processes  or  lifecycle  models 

•  Interface  standards 

•  Reusable  components 

•  Management  techniques  and  methodologies 

•  Quality  improvement  techniques  and  methodologies 

•  Development  techniques  and  methodologies 


Some  suggested  improvements  may  be  received  in  the  form  of  a  proposal 
(e.g.,  an  organizational  improvement  proposal  arising  from  a  causal 
analysis  and  resolution  activity).  These  suggested  improvements  will  have 
been  analyzed  and  documented  prior  to  input  to  Organizational 
Performance  Management  processes.  When  suggested  improvements  are 
received  as  proposals,  the  proposals  are  reviewed  for  completeness  and 
are  evaluated  as  part  of  the  selection  process  for  implementation. 

Improvement  searches  can  involve  looking  outside  the  organization, 
deriving  innovations  from  projects  using  Causal  Analysis  and  Resolution 
processes,  using  competitive  business  intelligence,  or  analyzing  existing 
organizational  performance. 

Example  Work  Products 

1 .  Suggested  incremental  improvements 

2.  Suggested  innovative  improvements 

Subpractices 

1 .  Elicit  suggested  improvements. 

These  suggestions  document  potential  improvements  to  processes  and  technologies. 
Managers  and  staff  in  the  organization  as  well  as  customers,  end  users,  and  suppliers 
can  submit  suggestions.  The  organization  can  also  search  the  academic  and 
technology  communities  for  suggested  improvements.  Some  suggested  improvements 
may  have  been  implemented  at  the  project  level  before  being  proposed  for  the 
organization. 
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Examples  of  sources  for  improvements  include  the  following: 

•  Findings  and  recommendations  from  process  appraisals 

•  The  organization's  quality  and  process  performance  objectives 

•  Analysis  of  data  about  customer  and  end-user  problems  as  well  as  customer  and  end- 
user  satisfaction 

•  Results  of  process  and  product  benchmarking  efforts 

•  Measured  effectiveness  of  process  activities 

•  Measured  effectiveness  of  project  work  environments 

•  Examples  of  improvements  that  were  successfully  adopted  elsewhere 

•  Feedback  on  previous  improvements 

•  Spontaneous  ideas  from  managers  and  staff 

•  Improvement  proposals  from  Causal  Analysis  and  Resolution  processes  resulting  from 
implemented  actions  with  proven  effectiveness 

•  Analysis  of  technical  performance  measures 

•  Analysis  of  data  on  defect  causes 

•  Analysis  of  project  and  organizational  performance  compared  to  quality  and 
productivity  objectives 


Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  deploying  organizational  process  assets  and 
incorporating  experiences. 

2.  Identify  suggested  improvements  as  incremental  or  innovative. 

3.  Investigate  innovative  improvements  that  may  improve  the 
organization's  processes  and  technologies. 

f. - 

I  Investigating  innovative  improvements  typically  involves  the  following: 

I  •  Maintaining  awareness  of  leading  relevant  technical  work  and  technology  trends 
I  •  Searching  for  commercially  available  innovative  improvements 

:  •  Collecting  proposals  for  innovative  improvements  from  the  projects  and  the 
I  organization 

I  •  Reviewing  processes  and  technologies  used  externally  and  comparing  them  to  the 
I  processes  and  technologies  used  in  the  organization 

I  •  Identifying  areas  where  innovative  improvements  have  been  used  successfully,  and 
;  reviewing  data  and  documentation  of  experience  using  these  improvements 

i  •  Identifying  improvements  that  integrate  new  technology  into  products  and  project  work 
;  environments 


SP  2.2  Analyze  Suggested  Improvements 

Analyze  suggested  improvements  for  their  possible  impact  on 
achieving  the  organization’s  quality  and  process  performance 
objectives. 

Suggested  improvements  are  incremental  and  innovative  improvements 
that  are  analyzed  and  possibly  selected  for  validation,  implementation,  and 
deployment  throughout  the  organization. 
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Example  Work  Products 

1 .  Suggested  improvement  proposals 

2.  Selected  improvements  to  be  validated 

Subpractices 

1 .  Analyze  the  costs  and  benefits  of  suggested  improvements. 

Process  performance  models  provide  insight  into  the  effect  of  process  changes  on 
process  capability  and  performance. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  establishing  process  performance  models. 

Improvement  suggestions  that  have  a  large  cost-to-benefit  ratio  or  that  would  not 
improve  the  organization’s  processes  may  be  rejected. 

:  Criteria  for  evaluating  costs  and  benefits  include  the  following: 

i  •  Contribution  toward  meeting  the  organization's  quality  and  process  performance 

;  objectives 

i  •  Effect  on  mitigating  identified  project  and  organizational  risks 

i  •  Ability  to  respond  quickly  to  changes  in  project  requirements,  market  situations,  and 
;  the  business  environment 

;  •  Effect  on  related  processes  and  associated  assets 

;  •  Cost  of  defining  and  collecting  data  that  support  the  measurement  and  analysis  of  the 
i  process  and  technology  improvement 

i  •  Expected  life  span  of  the  improvement 


2.  Identify  potential  barriers  and  risks  to  deploying  each  suggested 
improvement. 

:  Examples  of  barriers  to  deploying  improvements  include  the  following: 

I  •  Turf  guarding  and  parochial  perspectives 

i  •  Unclear  or  weak  business  rationale 

i  •  Lack  of  short-term  benefits  and  visible  successes 

i  •  Unclear  picture  of  what  is  expected  from  everyone 

;  •  Too  many  changes  at  the  same  time 

;  •  Lack  of  involvement  and  support  from  relevant  stakeholders 
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Examples  of  risk  factors  that  affect  the  deployment  of  improvements  include  the 
following: 

•  Compatibility  of  the  improvement  with  existing  processes,  values,  and  skills  of  potential 
end  users 

•  Complexity  of  the  improvement 

•  Difficulty  implementing  the  improvement 

•  Ability  to  demonstrate  the  value  of  the  improvement  before  widespread  deployment 

•  Justification  for  large,  up-front  investments  in  areas  such  as  tools  and  training 

•  Inability  to  overcome  “technology  drag”  where  the  current  implementation  is  used 
successfully  by  a  large  and  mature  installed  base  of  end  users 


3.  Estimate  the  cost,  effort,  and  schedule  required  for  implementing, 
verifying,  and  deploying  each  suggested  improvement. 

4.  Select  suggested  improvements  for  validation  and  possible 
implementation  and  deployment  based  on  the  evaluations. 

Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai 
evaiuation  process  that  evaiuates  identified  aiternatives  against 
estabiished  criteria. 

5.  Document  the  evaluation  results  of  each  selected  improvement 
suggestion  in  an  improvement  proposal. 

The  proposal  should  include  a  problem  statement,  a  plan  (including  cost  and  schedule, 
risk  handling,  method  for  evaluating  effectiveness  in  the  target  environment)  for 
implementing  the  improvement,  and  quantitative  success  criteria  for  evaluating  actual 
results  of  the  deployment. 

6.  Determine  the  detailed  changes  needed  to  implement  the  improvement 
and  document  them  in  the  improvement  proposal. 

7.  Determine  the  validation  method  that  will  be  used  before  broad-scale 
deployment  of  the  change  and  document  it  in  the  improvement 
proposal. 

Determining  the  validation  method  includes  defining  the  quantitative  success  criteria  that 
will  be  used  to  evaluate  results  of  the  validation. 

Since  innovations,  by  definition,  represent  a  major  change  with  high  impact,  most 
innovative  improvements  will  be  piloted.  Other  validation  methods,  including  modeling  and 
simulation  can  be  used  as  appropriate. 

8.  Document  results  of  the  selection  process. 

:  Results  of  the  selection  process  usually  include  the  following: 

i  •  The  disposition  of  each  suggested  improvement 
i  •  The  rationale  for  the  disposition  of  each  suggested  improvement 


SP  2.3  Validate  Improvements 

Validate  selected  Improvements. 
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Selected  improvements  are  validated  in  accordance  with  their  improvement 
proposals. 

Examples  of  validation  methods  include  the  following: 

•  Discussions  with  stakeholders,  perhaps  in  the  context  of  a  formal  review 

•  Prototype  demonstrations 

•  Pilots  of  suggested  improvements 

•  Modeling  and  simulation 


Pilots  can  be  conducted  to  evaluate  significant  changes  involving  untried, 
high-risk,  or  innovative  improvements  before  they  are  broadly  deployed.  Not 
all  improvements  need  the  rigor  of  a  pilot.  Criteria  for  selecting 
improvements  for  piloting  are  defined  and  used.  Factors  such  as  risk, 
transformational  nature  of  change,  or  number  of  functional  areas  affected 
will  determine  the  need  for  a  pilot  of  the  improvement. 

Red-lined  or  rough-draft  process  documentation  can  be  made  available  for 
use  in  piloting. 

Example  Work  Products 

1.  Validation  plans 

2.  Validation  evaluation  reports 

3.  Documented  lessons  learned  from  validation 

Subpractices 

1.  Plan  the  validation. 

Quantitative  success  criteria  documented  in  the  improvement  proposal  can  be  useful 
when  planning  validation. 

Validation  plans  for  selected  improvements  to  be  piloted  should  include  target  projects, 
project  characteristics,  a  schedule  for  reporting  results,  and  measurement  activities. 

2.  Review  and  get  relevant  stakeholder  agreement  on  validation  plans. 

3.  Consult  with  and  assist  those  who  perform  the  validation. 

4.  Create  a  trial  implementation,  in  accordance  with  the  validation  plan, 
for  selected  improvements  to  be  piloted. 

5.  Perform  each  validation  in  an  environment  that  is  similar  to  the 
environment  present  in  a  broad  scale  deployment. 

6.  Track  validation  against  validation  plans. 

7.  Review  and  document  the  results  of  validation. 

Validation  results  are  evaluated  using  the  quantitative  criteria  defined  in  the 
improvement  proposal. 
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Reviewing  and  documenting  resuits  of  piiots  typicaiiy  invoives  the  foiiowing  activities: 

•  Reviewing  pilot  results  with  stakeholders 

•  Deciding  whether  to  terminate  the  pilot,  rework  implementation  of  the  improvement, 
replan  and  continue  the  pilot,  or  proceed  with  deployment 

•  Updating  the  disposition  of  improvement  proposals  associated  with  the  pilot 

•  Identifying  and  documenting  new  improvement  proposals  as  appropriate 

•  Identifying  and  documenting  lessons  learned  and  problems  encountered  during  the 
pilot  including  feedback  to  the  improvement  team  and  changes  to  the  improvement 


SP  2.4  Select  and  Implement  Improvements  for  Deployment 

Select  and  implement  improvements  for  deployment  throughout 
the  organization  based  on  an  evaluation  of  costs,  benefits,  and 
other  factors. 

Selection  of  suggested  improvements  for  deployment  is  based  on  cost-to- 
benefit  ratios  with  regard  to  quality  and  process  performance  objectives, 
available  resources,  and  the  results  of  improvement  proposal  evaluation 
and  validation  activities. 

Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai  evaiuation 
process  that  evaiuates  identified  aiternatives  against  estabiished  criteria. 

Example  Work  Products 

1 .  Improvements  selected  for  deployment 

2.  Updated  process  documentation  and  training 
Subpractices 

1 .  Prioritize  improvements  for  deployment. 

The  priority  of  an  improvement  is  based  on  an  evaiuation  of  its  estimated  cost-to- 
benefit  ratio  with  regard  to  the  quaiity  and  process  performance  objectives  as 
compared  to  the  performance  baseiines.  Return  on  investment  can  be  used  as  a  basis 
of  comparison. 

2.  Select  improvements  to  be  deployed. 

Selection  of  improvements  to  be  depioyed  is  based  on  their  priorities,  avaiiabie 
resources,  and  resuits  of  improvement  proposai  evaiuation  and  vaiidation  activities. 

3.  Determine  how  to  deploy  each  improvement. 

;  Exampies  of  where  the  improvements  may  be  depioyed  inciude  the  foiiowing: 

;  •  Project  specific  or  common  work  environments 
I  •  Product  families 
I  •  Organization's  projects 
I  •  Organizational  groups 

4.  Document  results  of  the  selection  process. 
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Results  of  the  selection  process  usually  include  the  following: 

•  The  selection  criteria  for  suggested  improvements 

•  The  characteristics  of  the  target  projects 

•  The  disposition  of  each  improvement  proposal 

•  The  rationale  for  the  disposition  of  each  improvement  proposal 


5.  Review  any  changes  needed  to  implement  the  improvements. 

:  Examples  of  changes  needed  to  deploy  an  improvement  include  the  following: 

i  •  Process  descriptions,  standards,  and  procedures 
i  •  Work  environments 
i  •  Education  and  training 
I  •  Skills 

;  •  Existing  commitments 
i  •  Existing  activities 
i  •  Continuing  support  to  end  users 
I  •  Organizational  culture  and  characteristics 

6.  Update  the  organizational  process  assets. 

;  Updating  the  organizational  process  assets  typically  includes  reviewing  them,  gaining 
i  approval  for  them,  and  communicating  them. 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets. 

SG  3 _ Deploy  Improvements _ 

Measurable  improvements  to  the  organization’s  processes  and  technologies 
are  deployed  and  evaluated  using  statistical  and  other  quantitative 
techniques. 

Once  improvements  are  selected  for  deployment,  a  plan  for  deployment  is 
created  and  executed.  The  deployment  of  improvements  is  managed  and 
the  effects  of  the  improvements  are  measured  and  evaluated  as  to  how  well 
they  contribute  to  meeting  quality  and  process  performance  objectives. 

SP  3.1  Plan  the  Deployment 

Establish  and  maintain  plans  for  deploying  selected  improvements. 

The  plans  for  deploying  selected  improvements  can  be  included  in  the  plan 
for  organizational  performance  management,  in  improvement  proposals,  or 
in  separate  deployment  documents. 

This  specific  practice  complements  the  Deploy  Organizational  Process 
Assets  specific  practice  in  the  Organizational  Process  Focus  process  area 
and  adds  the  use  of  quantitative  data  to  guide  the  deployment  and  to 
determine  the  value  of  improvements. 
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Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  deploying  organizational  process  assets  and 
incorporating  experiences. 

Example  Work  Products 

1 .  Deployment  plans  for  selected  improvements 
Subpractices 

1 .  Determine  how  each  improvement  should  be  adjusted  for  deployment. 

Improvements  identified  in  a  limited  context  (e.g.,  for  a  single  improvement  proposal) 
might  need  to  be  modified  for  a  selected  portion  of  the  organization. 

2.  Identify  strategies  that  address  the  potential  barriers  to  deploying  each 
improvement  that  were  defined  in  the  improvement  proposals. 

3.  Identify  the  target  project  population  for  deployment  of  the 
improvement. 

Not  all  projects  are  good  candidates  for  all  improvements.  For  example,  improvements 
may  be  targeted  to  software  only  projects,  COTS  integration  projects,  or  operations 
and  support  projects. 

4.  Establish  measures  and  objectives  for  determining  the  value  of  each 
improvement  with  respect  to  the  organization’s  quality  and  process 
performance  objectives. 

Measures  can  be  based  on  the  quantitative  success  criteria  documented  in  the 
improvement  proposal  or  derived  from  organizational  objectives. 

;  Examples  of  measures  for  determining  the  value  of  an  improvement  include  the 
i  following: 

i  •  Measured  improvement  in  the  project's  or  organization's  process  performance 
i  •  Time  to  recover  the  cost  of  the  improvement 

i  •  Number  and  types  of  project  and  organizational  risks  mitigated  by  the  process  or 
i  technology  improvement 

;  •  Average  time  required  to  respond  to  changes  in  project  requirements,  market 
i  situations,  and  the  business  environment 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  aligning  measurement  and  analysis  activities  and 
providing  measurement  results. 

5.  Document  the  plans  for  deploying  selected  improvements. 

The  deployment  plans  should  include  relevant  stakeholders,  risk  strategies,  target 
projects,  measures  of  success,  and  schedule. 

6.  Review  and  get  agreement  with  relevant  stakeholders  on  the  plans  for 
deploying  selected  improvements. 

Relevant  stakeholders  include  the  improvement  sponsor,  target  projects,  support 
organizations,  etc. 

7.  Revise  the  plans  for  deploying  selected  improvements  as  necessary. 


Organizational  Performance  Management  (0PM) 


231 


CMMI  for  Development,  Version  1.3 


SP  3.2  Manage  the  Deployment 

Manage  the  deployment  of  selected  Improvements. 

This  specific  practice  can  overlap  with  the  Implement  Action  Proposals 
specific  practice  in  the  Causal  Analysis  and  Resolution  process  area  (e.g., 
when  causal  analysis  and  resolution  is  used  organizationally  or  across 
multiple  projects). 

Example  Work  Products 

1 .  Updated  training  materials  (to  reflect  deployed  improvements) 

2.  Documented  results  of  improvement  deployment  activities 

3.  Revised  improvement  measures,  objectives,  priorities,  and  deployment 
plans 

Subpractices 

1 .  Monitor  the  deployment  of  improvements  using  deployment  plans. 

2.  Coordinate  the  deployment  of  improvements  across  the  organization, 
i  Coordinating  deployment  includes  the  following  activities: 

;  •  Coordinating  activities  of  projects,  support  groups,  and  organizational  groups  for  each 
i  Improvement 

;  •  Coordinating  activities  for  deploying  related  Improvements 

3.  Deploy  improvements  in  a  controlled  and  disciplined  manner. 

;  Examples  of  methods  for  deploying  Improvements  Include  the  following: 

i  •  Deploying  Improvements  Incrementally  rather  than  as  a  single  deployment 

i  •  Providing  comprehensive  consulting  to  early  adopters  of  Improvement  In  lieu  of  revised 
;  formal  training 


4.  Coordinate  the  deployment  of  improvements  into  the  projects’  defined 
processes  as  appropriate. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  deploying  organizational  process  assets  and 
incorporating  experiences. 

5.  Provide  consulting  as  appropriate  to  support  deployment  of 
improvements. 

6.  Provide  updated  training  materials  or  develop  communication 
packages  to  reflect  improvements  to  organizational  process  assets. 

Refer  to  the  Organizational  Training  process  area  for  more  information 
about  providing  training. 

7.  Confirm  that  the  deployment  of  all  improvements  is  completed  in 
accordance  with  the  deployment  plan. 

8.  Document  and  review  results  of  improvement  deployment. 
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I  Documenting  and  reviewing  results  includes  the  following: 

I  •  Identifying  and  documenting  lessons  learned 
•  Revising  improvement  measures,  objectives,  priorities,  and  deployment  plans 


SP  3.3  Evaluate  Improvement  Effects 

Evaluate  the  effects  of  deployed  Improvements  on  quality  and 
process  performance  using  statistical  and  other  quantitative 
techniques. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  aligning  measurement  and  analysis  activities  and  providing 
measurement  results. 

This  specific  practice  can  overlap  with  the  Evaluate  the  Effect  of 
Implemented  Actions  specific  practice  in  the  Causal  Analysis  and 
Resolution  process  area  (e.g.,  when  causal  analysis  and  resolution  is 
applied  organizationally  or  across  multiple  projects). 

Example  Work  Products 

1 .  Documented  measures  of  the  effects  resulting  from  deployed 
improvements 

Subpractices 

1 .  Measure  the  results  of  each  improvement  as  implemented  on  the 
target  projects,  using  the  measures  defined  in  the  deployment  plans. 

2.  Measure  and  analyze  progress  toward  achieving  the  organization’s 
quality  and  process  performance  objectives  using  statistical  and  other 
quantitative  techniques  and  take  corrective  action  as  needed. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  establishing  quality  and  process  performance 
objectives  and  establishing  process  performance  baselines  and 
models. 
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ORGANIZATIONAL  PROCESS  PERFORMANCE 

A  Process  Management  Process  Area  at  Maturity  Level  4 


Purpose 


The  purpose  of  Organizational  Process  Performance  (OPP)  is  to  establish 
and  maintain  a  quantitative  understanding  of  the  performance  of  selected 
processes  in  the  organization’s  set  of  standard  processes  in  support  of 
achieving  quality  and  process  performance  objectives,  and  to  provide 
process  performance  data,  baselines,  and  models  to  quantitatively  manage 
the  organization’s  projects. 


Introductory  Notes 


The  Organizational  Process  Performance  process  area  involves  the 
following  activities: 

•  Establishing  organizational  quantitative  quality  and  process 
performance  objectives  based  on  business  objectives  (See  the 
definition  of  “quality  and  process  performance  objectives”  in  the 
glossary.) 

•  Selecting  processes  or  subprocesses  for  process  performance 
analyses 

•  Establishing  definitions  of  the  measures  to  be  used  in  process 
performance  analyses  (See  the  definition  of  “process 
performance”  in  the  glossary.) 

•  Establishing  process  performance  baselines  and  process 
performance  models  (See  the  definitions  of  “process  performance 
baselines”  and  “process  performance  models”  in  the  glossary.) 

The  collection  and  analysis  of  the  data  and  creation  of  the  process 
performance  baselines  and  models  can  be  performed  at  different  levels  of 
the  organization,  including  individual  projects  or  groups  of  related  projects 
as  appropriate  based  on  the  needs  of  the  projects  and  organization. 

The  common  measures  for  the  organization  consist  of  process  and  product 
measures  that  can  be  used  to  characterize  the  actual  performance  of 
processes  in  the  organization’s  individual  projects.  By  analyzing  the 
resulting  measurements,  a  distribution  or  range  of  results  can  be 
established  that  characterize  the  expected  performance  of  the  process 
when  used  on  an  individual  project. 

Measuring  quality  and  process  performance  can  involve  combining  existing 
measures  into  additional  derived  measures  to  provide  more  insight  into 
overall  efficiency  and  effectiveness  at  a  project  or  organization  level.  The 
analysis  at  the  organization  level  can  be  used  to  study  productivity,  improve 
efficiencies,  and  increase  throughput  across  projects  in  the  organization. 
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The  expected  process  performance  can  be  used  in  establishing  the 
project’s  quality  and  process  performance  objectives  and  can  be  used  as  a 
baseline  against  which  actual  project  performance  can  be  compared.  This 
information  is  used  to  quantitatively  manage  the  project.  Each  quantitatively 
managed  project,  in  turn,  provides  actual  performance  results  that  become 
a  part  of  organizational  process  assets  that  are  made  available  to  all 
projects. 

Process  performance  models  are  used  to  represent  past  and  current 
process  performance  and  to  predict  future  results  of  the  process.  For 
example,  the  latent  defects  in  the  delivered  product  can  be  predicted  using 
measurements  of  work  product  attributes  such  as  complexity  and  process 
attributes  such  as  preparation  time  for  peer  reviews. 

When  the  organization  has  sufficient  measures,  data,  and  analytical 
techniques  for  critical  process,  product,  and  service  characteristics,  it  is 
able  to  do  the  following: 

•  Determine  whether  processes  are  behaving  consistently  or  have  stable 
trends  (i.e.,  are  predictable) 

•  Identify  processes  in  which  performance  is  within  natural  bounds  that 
are  consistent  across  projects  and  could  potentially  be  aggregated 

•  Identify  processes  that  show  unusual  (e.g.,  sporadic,  unpredictable) 
behavior 

•  Identify  aspects  of  processes  that  can  be  improved  in  the  organization’s 
set  of  standard  processes 

•  Identify  the  implementation  of  a  process  that  performs  best 

This  process  area  interfaces  with  and  supports  the  implementation  of  other 
high  maturity  process  areas.  The  assets  established  and  maintained  as  part 
of  implementing  this  process  area  (e.g.,  the  measures  to  be  used  to 
characterize  subprocess  behavior,  process  performance  baselines,  process 
performance  models)  are  inputs  to  the  quantitative  project  management, 
causal  analysis  and  resolution,  and  organizational  performance 
management  processes  in  support  of  the  analyses  described  there. 
Quantitative  project  management  processes  provide  the  quality  and 
process  performance  data  needed  to  maintain  the  assets  described  in  this 
process  area. 

Related  Process  Areas 


Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  specifying  measures,  obtaining  measurement  data,  and  analyzing 
measurement  data. 

Refer  to  the  Organizational  Performance  Management  process  area  for 
more  information  about  proactively  managing  the  organization’s 
performance  to  meet  its  business  objectives. 
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Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  quantitativeiy  managing  the  project  to  achieve  the 
project’s  established  quality  and  process  performance  objectives. 


Specific  Goai  and  Practice  Summary 

SG  1  Establish  Performance  Baselines  and  Models 

SP  1 .1  Establish  Quality  and  Process  Performance  Objectives 

SP  1 .2  Select  Processes 

SP  1 .3  Establish  Process  Performance  Measures 

SP  1 .4  Analyze  Process  Performance  and  Establish  Process  Performance  Baselines 
SP  1 .5  Establish  Process  Performance  Models 


Specific  Practices  by  Goai 


SG  1  Establish  Performance  Baselines  and  Models 

Baselines  and  models,  which  characterize  the  expected  process  performance 
of  the  organization’s  set  of  standard  processes,  are  established  and 
maintained. 

Prior  to  establishing  process  performance  baselines  and  models,  it  is 
necessary  to  determine  the  quality  and  process  performance  objectives  for 
those  processes  (the  Establish  Quality  and  Process  Performance 
Objectives  specific  practice),  which  processes  are  suitable  to  be  measured 
(the  Select  Processes  specific  practice),  and  which  measures  are  useful  for 
determining  process  performance  (the  Establish  Process  Performance 
Measures  specific  practice). 

The  first  three  practices  of  this  goal  are  interrelated  and  often  need  to  be 
performed  concurrently  and  iteratively  to  select  quality  and  process 
performance  objectives,  processes,  and  measures.  Often,  the  selection  of 
one  quality  and  process  performance  objective,  process,  or  measure  will 
constrain  the  selection  of  the  others.  For  example,  selecting  a  quality  and 
process  performance  objective  relating  to  defects  delivered  to  the  customer 
will  almost  certainly  require  selecting  the  verification  processes  and  defect 
related  measures. 

The  intent  of  this  goal  is  to  provide  projects  with  the  process  performance 
baselines  and  models  they  need  to  perform  quantitative  project 
management.  Many  times  these  baselines  and  models  are  collected  or 
created  by  the  organization,  but  there  are  circumstances  in  which  a  project 
may  need  to  create  the  baselines  and  models  for  themselves.  These 
circumstances  include  projects  that  are  not  covered  by  the  organization’s 
baselines  and  models.  For  these  cases  the  project  follows  the  practices  in 
this  goal  to  create  its  baselines  and  models. 

SP  1.1  Establish  Quality  and  Process  Performance  Objectives 

Establish  and  maintain  the  organization’s  quantitative  objectives 
for  quality  and  process  performance,  which  are  traceable  to 
business  objectives. 

The  organization’s  quality  and  process  performance  objectives  can  be 
established  for  different  levels  in  the  organizational  structure  (e.g.,  business 
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area,  product  line,  function,  project)  as  well  as  at  different  levels  in  the 
process  hierarchy.  When  establishing  quality  and  process  performance 
objectives,  consider  the  following: 

•  Traceability  to  the  organization’s  business  objectives 

•  Past  performance  of  the  selected  processes  or  subprocesses  in  context 
(e.g.,  on  projects) 

•  Multiple  attributes  of  process  performance  (e.g.,  product  quality, 
productivity,  cycle  time,  response  time) 

•  Inherent  variability  or  natural  bounds  of  the  selected  processes  or 
subprocesses 

The  organization’s  quality  and  process  performance  objectives  provide 
focus  and  direction  to  the  process  performance  analysis  and  quantitative 
project  management  activities.  However,  it  should  be  noted  that  achieving 
quality  and  process  performance  objectives  that  are  significantly  different 
from  current  process  capability  requires  use  of  techniques  found  in  Causal 
Analysis  and  Resolution  and  Organizational  Performance  Management. 

Example  Work  Products 

1 .  Organization’s  quality  and  process  performance  objectives 
Subpractices 

1 .  Review  the  organization’s  business  objectives  related  to  quality  and 
process  performance. 

;  Examples  of  business  objectives  include  the  following: 

i  •  Deliver  products  within  budget  and  on  time 
I  •  Improve  product  quality  by  a  specified  percent  in  a  specified  timeframe 
I  •  Improve  productivity  by  a  specified  percent  in  a  specified  timeframe 
;  •  Maintain  customer  satisfaction  ratings 

;  •  Improve  time-to-market  for  new  product  or  service  releases  by  a  specified  percent  in  a 
I  specified  timeframe 

I  •  Reduce  deferred  product  functionality  by  a  specified  percent  in  a  specified  timeframe 
I  •  Reduce  the  rate  of  product  recalls  by  a  specified  percent  in  a  specified  timeframe 

I  •  Reduce  customer  total  cost  of  ownership  by  a  specified  percent  in  a  specified 
I  timeframe 

I  •  Decrease  the  cost  of  maintaining  legacy  products  by  a  specified  percent  in  a  specified 
I  timeframe 


2.  Define  the  organization’s  quantitative  objectives  for  quality  and  process 
performance. 

Quality  and  process  performance  objectives  can  be  established  for  process  or 
subprocess  measurements  (e.g.,  effort,  cycle  time,  defect  removal  effectiveness)  as 
well  as  for  product  measurements  (e.g.,  reliability,  defect  density)  and  service 
measurements  (e.g.,  capacity,  response  times)  as  appropriate. 
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Examples  of  quality  and  process  performance  objectives  include  the  following: 

•  Achieve  a  specified  defect  escape  rate,  productivity,  duration,  capacity,  or  cost  target 

•  Improve  the  defect  escape  rate,  productivity,  duration,  capacity,  or  cost  performance  by 
a  specified  percent  of  the  process  performance  baseline  in  a  specified  timeframe 

•  Improve  service  level  agreement  performance  by  a  specified  percent  of  the  process 
performance  baseline  in  a  specified  timeframe 


3.  Define  the  priorities  of  the  organization’s  objectives  for  quality  and 
process  performance. 

4.  Review,  negotiate,  and  obtain  commitment  to  the  organization’s  quality 
and  process  performance  objectives  and  their  priorities  from  relevant 
stakeholders. 

5.  Revise  the  organization’s  quantitative  objectives  for  quality  and 
process  performance  as  necessary. 

;  Examples  of  when  the  organization’s  quantitative  objectives  for  quality  and  process 
i  performance  may  need  to  be  revised  include  the  following: 

;  •  When  the  organization's  business  objectives  change 

;  •  When  the  organization's  set  of  standard  processes  change 

i  •  When  actual  quality  and  process  performance  differ  significantly  from  objectives 


SP  1 .2  Select  Processes 

Select  processes  or  subprocesses  in  the  organization’s  set  of 
standard  processes  to  be  included  in  the  organization’s  process 
performance  analyses  and  maintain  traceability  to  business 
objectives. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets. 

The  organization’s  set  of  standard  processes  consists  of  a  set  of  standard 
processes  that,  in  turn,  are  composed  of  subprocesses. 

Typically,  it  is  not  possible,  useful,  or  economically  justifiable  to  apply 
statistical  management  techniques  to  all  processes  or  subprocesses  of  the 
organization’s  set  of  standard  processes.  Selection  of  processes  or 
subprocesses  is  based  on  the  quality  and  process  performance  objectives 
of  the  organization,  which  are  derived  from  business  objectives  as 
described  in  the  previous  specific  practice. 

Example  Work  Products 

1 .  List  of  processes  or  subprocesses  identified  for  process  performance 
analyses  with  rationale  for  their  selection  including  traceability  to 
business  objectives 

Subpractices 

1 .  Establish  the  criteria  to  use  when  selecting  subprocesses. 
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Examples  of  criteria  that  can  be  used  for  the  selection  of  a  process  or  subprocess  for 

the  organization’s  process  performance  analysis  include  the  following: 

•  The  process  or  subprocess  is  strongly  related  to  key  business  objectives. 

•  The  process  or  subprocess  has  demonstrated  stability  in  the  past. 

•  Valid  historical  data  are  currently  available  that  is  relevant  to  the  process  or 
subprocess. 

•  The  process  or  subprocess  will  generate  data  with  sufficient  frequency  to  allow  for 
statistical  management. 

•  The  process  or  subprocess  is  an  important  contributor  to  quality  and  process 
performance. 

•  The  process  or  subprocess  is  an  important  predictor  of  quality  and  process 
performance. 

•  The  process  or  subprocess  is  a  factor  important  to  understanding  the  risk  associated 
with  achieving  the  quality  and  process  performance  objectives. 

•  The  quality  of  the  measures  and  measurements  associated  with  the  process  or 
subprocess  (e.g.,  measurement  system  error)  is  adequate. 

•  Multiple  measurable  attributes  that  characterize  process  or  subprocess  behavior  are 
available. 


2.  Select  the  subprocesses  and  document  the  rationale  for  their  selection. 

I  Example  approaches  to  identifying  and  evaluating  subprocess  alternatives  as  part  of  a 
;  selection  include  the  following: 

I  •  Causal  analysis 
I  •  Sensitivity  analysis 


Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai 
evaiuation  process  that  evaiuates  identified  aiternatives  against 
estabiished  criteria. 

3.  Establish  and  maintain  traceability  between  the  selected 

subprocesses,  quality  and  process  performance  objectives,  and 
business  objectives. 

:  Examples  of  ways  in  which  traceability  can  be  expressed  include  the  following: 

i  •  Mapping  of  subprocesses  to  quality  and  process  performance  objectives 
i  •  Mapping  of  subprocesses  to  business  objectives 
i  •  Objective  flow-down  (e.g.,  Big  Y  to  Vital  X,  Hoshin  planning) 

;  •  Balanced  scorecard 
;  •  Quality  Function  Deployment  (QFD) 
i  •  Goal  Question  Metric 

i  •  Documentation  for  a  process  performance  model 


4.  Revise  the  selection  as  necessary. 

It  may  be  necessary  to  revise  the  selection  in  the  following  situations: 
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•  The  predictions  made  by  process  performance  modeis  resuit  in  too  much  variation  to 
make  them  usefui. 

•  The  objectives  for  quaiity  and  process  performance  change. 

•  The  organization's  set  of  standard  processes  change. 

•  The  underiying  quaiity  and  process  performance  changes. 

SP  1.3  Establish  Process  Performance  Measures 

Establish  and  maintain  definitions  of  measures  to  be  included  in 
the  organization’s  process  performance  analyses. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  specifying  measures. 

Example  Work  Products 

1 .  Definitions  of  selected  measures  of  process  performance  with  rationale 
for  their  selection  including  traceability  to  selected  processes  or 
subprocesses 

Subpractices 

1 .  Select  measures  that  reflect  appropriate  attributes  of  the  selected 
processes  or  subprocesses  to  provide  insight  into  the  organization’s 
quality  and  process  performance. 

It  is  often  helpful  to  define  multiple  measures  for  a  process  or  subprocess  to 
understand  the  impact  of  changes  to  the  process  and  avoid  sub-optimization.  Also,  it  is 
often  helpful  to  establish  measures  for  both  product  and  process  attributes  for  the 
selected  process  and  subprocess,  as  well  as  its  inputs,  outputs,  and  resources 
(including  people  and  the  skill  they  bring)  consumed. 

The  Goal  Question  Metric  paradigm  is  an  approach  that  can  be  used  to  select 
measures  that  provide  insight  into  the  organization’s  quality  and  process  performance 
objectives.  It  is  often  useful  to  analyze  how  these  quality  and  process  performance 
objectives  can  be  achieved  based  on  an  understanding  of  process  performance 
provided  by  the  selected  measures. 

i  Examples  of  criteria  used  to  select  measures  include  the  following: 

;  •  Relationship  of  measures  to  the  organization's  quality  and  process  performance 
i  objectives 

;  •  Coverage  that  measures  provide  over  the  life  of  the  product  or  service 
i  •  Visibility  that  measures  provide  into  process  performance 
i  •  Availability  of  measures 

I  •  Frequency  at  which  observations  of  the  measure  can  be  collected 
I  •  Extent  to  which  measures  are  controllable  by  changes  to  the  process  or  subprocess 

;  •  Extent  to  which  measures  represent  the  end  users'  view  of  effective  process 
I  performance 


2.  Establish  operational  definitions  for  the  selected  measures. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  specifying  measures. 
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3.  Incorporate  selected  measures  into  the  organization’s  set  of  common 
measures. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets. 

4.  Revise  the  set  of  measures  as  necessary. 

Measures  are  periodically  evaluated  for  their  continued  usefulness  and  ability  to 
Indicate  process  effectiveness. 

SP  1 .4  Analyze  Process  Performance  and  Establish  Process  Performance 
Baselines 

Analyze  the  performance  of  the  selected  processes,  and  establish 
and  maintain  the  process  performance  baselines. 

The  selected  measures  are  analyzed  to  characterize  the  performance  of  the 
selected  processes  or  subprocesses  achieved  on  projects.  This 
characterization  is  used  to  establish  and  maintain  process  performance 
baselines  (See  the  definition  of  “process  performance  baseline”  in  the 
glossary.)  These  baselines  are  used  to  determine  the  expected  results  of 
the  process  or  subprocess  when  used  on  a  project  under  a  given  set  of 
circumstances. 

Process  performance  baselines  are  compared  to  the  organization’s  quality 
and  process  performance  objectives  to  determine  if  the  quality  and  process 
performance  objectives  are  being  achieved. 

The  process  performance  baselines  are  a  measurement  of  performance  for 
the  organization’s  set  of  standard  processes  at  various  levels  of  detail.  The 
processes  that  the  process  performance  baselines  can  address  include  the 
following: 

•  Sequence  of  connected  processes 

•  Processes  that  cover  the  entire  life  of  the  project 

•  Processes  for  developing  individual  work  products 

There  can  be  several  process  performance  baselines  to  characterize 
performance  for  subgroups  of  the  organization. 

;  Examples  of  criteria  used  to  categorize  subgroups  include  the  following: 

;  •  Product  line 

i  •  Line  of  business 

i  •  Application  domain 

i  •  Complexity 

I  •  Team  size 

I  •  Work  product  size 

;  •  Process  elements  from  the  organization’s  set  of  standard  processes 


Tailoring  the  organization’s  set  of  standard  processes  can  significantly 
affect  the  comparability  of  data  for  inclusion  in  process  performance 
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baselines.  Effects  of  tailoring  should  be  considered  in  establishing 
baselines.  Depending  on  the  tailoring  allowed,  separate  performance 
baselines  may  exist  for  each  type  of  tailoring. 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  quantitativeiy  managing  the  project  to  achieve  the 
project’s  established  quality  and  process  performance  objectives. 

Example  Work  Products 

1 .  Analysis  of  process  performance  data 

2.  Baseline  data  on  the  organization’s  process  performance 
Subpractices 

1 .  Collect  the  selected  measurements  for  the  selected  processes  and 
subprocesses. 

The  process  or  subprocess  in  use  when  the  measurement  was  taken  is  recorded  to 
enabie  its  use  iater. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  specifying  measurement  data  collection  and  storage 
procedures. 

2.  Analyze  the  collected  measures  to  establish  a  distribution  or  range  of 
results  that  characterize  the  expected  performance  of  selected 
processes  or  subprocesses  when  used  on  a  project. 

This  anaiysis  shouid  inciude  the  stabiiity  of  the  reiated  process  or  subprocess,  and  the 
impacts  of  associated  factors  and  context.  Reiated  factors  inciude  inputs  to  the 
process  and  other  attributes  that  can  affect  the  resuits  obtained.  The  context  inciudes 
the  business  context  (e.g.,  domain)  and  significant  taiioring  of  the  organization’s  set  of 
standard  processes. 

The  measurements  from  stabie  subprocesses  in  projects  shouid  be  used  when 
possibie;  other  data  may  not  be  reiiabie. 

3.  Establish  and  maintain  the  process  performance  baselines  from 
collected  measurements  and  analyses. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  aligning  measurement  and  analysis  activities  and 
providing  measurement  results. 

Process  performance  baselines  are  derived  by  analyzing  collected  measures  to 
establish  a  distribution  or  range  of  results  that  characterize  the  expected  performance 
for  selected  processes  or  subprocesses  when  used  on  a  project  in  the  organization. 

4.  Review  and  get  agreement  with  relevant  stakeholders  about  the 
process  performance  baselines. 

5.  Make  the  process  performance  information  available  across  the 
organization  in  the  measurement  repository. 

The  organization’s  process  performance  baselines  are  used  by  projects  to  estimate 
the  natural  bounds  for  process  performance. 
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6.  Compare  the  process  performance  baselines  to  associated  quality  and 
process  performance  objectives  to  determine  if  those  quality  and 
process  performance  objectives  are  being  achieved. 

These  comparisons  should  use  statistical  techniques  beyond  a  simple  comparison  of 
the  mean  to  gauge  the  extent  of  quality  and  process  performance  objective 
achievement.  If  the  quality  and  process  performance  objectives  are  not  being 
achieved,  corrective  actions  should  be  considered. 

Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  determining  causes  of  selected  outcomes. 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  planning  and  implementing  process  actions. 

Refer  to  the  Organizational  Performance  Management  for  more 
information  about  analyzing  process  performance  data  and  identifying 
potential  areas  for  improvement. 

7.  Revise  the  process  performance  baselines  as  necessary. 

f. - - 

I  Examples  of  when  the  organization’s  process  performance  baselines  may  need  to  be 
;  revised  include  the  following: 

i  •  When  processes  change 
i  •  When  the  organization's  results  change 
I  •  When  the  organization's  needs  change 
I  •  When  suppliers'  processes  change 
;  •  When  suppliers  change 


SP  1.5  Establish  Process  Performance  Models 

Establish  and  maintain  process  performance  models  for  the 
organization’s  set  of  standard  processes. 

High  maturity  organizations  generally  establish  and  maintain  a  set  of 
process  performance  models  at  various  levels  of  detail  that  cover  a  range  of 
activities  that  are  common  across  the  organization  and  address  the 
organization’s  quality  and  process  performance  objectives.  (See  the 
definition  of  “process  performance  model”  in  the  glossary.)  Under  some 
circumstances,  projects  may  need  to  create  their  own  process  performance 
models. 

Process  performance  models  are  used  to  estimate  or  predict  the  value  of  a 
process  performance  measure  from  the  values  of  other  process,  product, 
and  service  measurements.  These  process  performance  models  typically 
use  process  and  product  measurements  collected  throughout  the  life  of  the 
project  to  estimate  progress  toward  achieving  quality  and  process 
performance  objectives  that  cannot  be  measured  until  later  in  the  project’s 
life. 

Process  performance  models  are  used  as  follows: 
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•  The  organization  uses  them  for  estimating,  analyzing,  and  predicting 
the  process  performance  associated  with  processes  in  and  changes  to 
the  organization’s  set  of  standard  processes. 

•  The  organization  uses  them  to  assess  the  (potential)  return  on 
investment  for  process  improvement  activities. 

•  Projects  use  them  for  estimating,  analyzing,  and  predicting  the  process 
performance  of  their  defined  processes. 

•  Projects  use  them  for  selecting  processes  or  subprocesses  for  use. 

•  Projects  use  them  for  estimating  progress  toward  achieving  the 
project’s  quality  and  process  performance  objectives. 

These  measures  and  models  are  defined  to  provide  insight  into  and  to 

provide  the  ability  to  predict  critical  process  and  product  characteristics  that 

are  relevant  to  the  organization’s  quality  and  process  performance 

objectives. 

Examples  of  process  performance  models  Include  the  following: 

•  System  dynamics  models 

•  Regression  models 

•  Complexity  models 

•  Discrete  event  simulation  models 

•  Monte  Carlo  simulation  models 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  quantitativeiy  managing  the  project  to  achieve  the 
project’s  established  quality  and  process  performance  objectives. 

Example  Work  Products 

1 .  Process  performance  models 

Subpractices 

1 .  Establish  process  performance  models  based  on  the  organization’s  set 
of  standard  processes  and  process  performance  baselines. 

2.  Calibrate  process  performance  models  based  on  the  past  results  and 
current  needs. 

3.  Review  process  performance  models  and  get  agreement  with  relevant 
stakeholders. 

4.  Support  the  projects’  use  of  process  performance  models. 

5.  Revise  process  performance  models  as  necessary. 

I  Examples  of  when  process  performance  models  may  need  to  be  revised  Include  the 
;  following: 

;  •  When  processes  change 
I  •  When  the  organization's  results  change 

I  •  When  the  organization's  quality  and  process  performance  objectives  change 
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ORGANIZATIONAL  TRAINING 


A  Process  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Organizational  Training  (OT)  is  to  develop  skills  and 
knowledge  of  people  so  they  can  perform  their  roles  effectively  and 
efficiently. 


Introductory  Notes 


Organizational  Training  addresses  training  provided  to  support  the 
organization’s  strategic  business  objectives  and  to  meet  the  tactical  training 
needs  that  are  common  across  projects  and  support  groups.  Training  needs 
identified  by  individual  projects  and  support  groups  to  meet  their  specific 
needs  are  handled  at  the  project  and  support  group  level  and  are  outside 
the  scope  of  the  Organizational  Training  process  area. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  needed  knowledge  and  skills. 

An  organizational  training  program  involves  the  following  activities: 

•  Identifying  the  training  needed  by  the  organization 

•  Obtaining  and  providing  training  to  address  those  needs 

•  Establishing  and  maintaining  a  training  capability 

•  Establishing  and  maintaining  training  records 

•  Assessing  training  effectiveness 

Effective  training  requires  the  assessment  of  needs,  planning,  instructional 
design,  and  appropriate  training  media  (e.g.,  workbooks,  computer 
software),  as  well  as  a  repository  of  training  process  data.  As  an 
organizational  process,  the  main  components  of  training  include  a  managed 
training  development  program,  documented  plans,  staff  with  an  appropriate 
mastery  of  disciplines  and  other  areas  of  knowledge,  and  mechanisms  for 
measuring  the  effectiveness  of  the  training  program. 

Identifying  process  training  needs  is  based  primarily  on  the  skills  required  to 
perform  the  organization’s  set  of  standard  processes. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  standard  processes. 

Certain  skills  can  be  effectively  and  efficiently  imparted  through  vehicles 
other  than  classroom  training  experiences  (e.g.,  informal  mentoring).  Other 
skills  require  more  formalized  training  vehicles,  such  as  in  a  classroom,  by 
web-based  training,  through  guided  self  study,  or  via  a  formalized  on-the- 
job  training  program.  The  formal  or  informal  training  vehicles  employed  for 
each  situation  should  be  based  on  an  assessment  of  the  need  for  training 
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and  the  performance  gap  to  be  addressed.  The  term  “training”  used 
throughout  this  process  area  is  used  broadly  to  include  all  of  these  learning 
options. 

Success  in  training  is  indicated  by  the  availability  of  opportunities  to  acquire 
the  skills  and  knowledge  needed  to  perform  new  and  ongoing  enterprise 
activities. 

Skills  and  knowledge  can  be  technical,  organizational,  or  contextual. 
Technical  skills  pertain  to  the  ability  to  use  equipment,  tools,  materials, 
data,  and  processes  required  by  a  project  or  process.  Organizational  skills 
pertain  to  behavior  within  and  according  to  the  staff  members’  organization 
structure,  role  and  responsibilities,  and  general  operating  principles  and 
methods.  Contextual  skills  are  the  self-management,  communication,  and 
interpersonal  abilities  needed  to  successfully  perform  work  in  the 
organizational  and  social  context  of  the  project  and  support  groups. 

Related  Process  Areas 


Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai  evaiuation 
process  that  evaiuates  identified  aiternatives  against  estabiished  criteria. 

Refer  to  the  Organizationai  Process  Definition  process  area  for  more 
information  about  estabiishing  organizationai  process  assets. 

Refer  to  the  Project  Pianning  process  area  for  more  information  about 
pianning  needed  knowiedge  and  skiiis. 

Specific  Goal  and  Practice  Summary 

SG  1  Establish  an  Organizational  Training  Capabiiity 
SP  1.1  Estabiish  Strategic  Training  Needs 

SP  1 .2  Determine  Which  Training  Needs  Are  the  Responsibility  of  the  Organization 

SP  1.3  Establish  an  Organizational  Training  Tactical  Plan 
SP  1 .4  Establish  a  Training  Capability 

SG  2  Provide  Training 

SP2.1  Deliver  Training 

SP  2.2  Establish  Training  Records 

SP  2.3  Assess  Training  Effectiveness 

Specific  Practices  by  Goal 


SG  1  Establish  an  Organizational  Training  Capability 

A  training  capabiiity,  which  supports  the  rotes  in  the  organization,  is 
estabiished  and  maintained. 

The  organization  identifies  training  required  to  develop  the  skills  and 
knowledge  necessary  to  perform  enterprise  activities.  Once  the  needs  are 
identified,  a  training  program  addressing  those  needs  is  developed. 

SP  1.1  Establish  Strategic  Training  Needs 

Estabiish  and  maintain  strategic  training  needs  of  the  organization. 
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Strategic  training  needs  address  long-term  objectives  to  build  a  capability 
by  filling  significant  knowledge  gaps,  introducing  new  technologies,  or 
implementing  major  changes  in  behavior.  Strategic  planning  typically  looks 
two  to  five  years  into  the  future. 

I  Examples  of  sources  of  strategic  training  needs  include  the  following: 

I  •  The  organization’s  standard  processes 
;  •  The  organization’s  strategic  business  plan 
i  •  The  organization’s  process  improvement  plan 
;  •  Enterprise  level  initiatives 

i  •  Skill  assessments 

:  •  Risk  analyses 

I  •  Acquisition  and  supplier  management 


Example  Work  Products 

1.  Training  needs 

2.  Assessment  analysis 

Subpractices 

1 .  Analyze  the  organization’s  strategic  business  objectives  and  process 
improvement  plan  to  identify  potential  training  needs. 

2.  Document  the  strategic  training  needs  of  the  organization. 

;  Examples  of  categories  of  training  needs  include  the  following: 

;  •  Process  analysis  and  documentation 

;  •  Engineering  (e.g.,  requirements  analysis,  design,  testing,  configuration  management, 

I  quality  assurance) 

I  •  Selection  and  management  of  suppliers 

I  •  Team  building 

I  •  Management  (e.g.,  estimating,  tracking,  risk  management) 

I  •  Leadership 

I  •  Disaster  recovery  and  continuity  of  operations 
•  Communication  and  negotiation  skills 

3.  Determine  the  roles  and  skills  needed  to  perform  the  organization’s  set 
of  standard  processes. 

4.  Document  the  training  needed  to  perform  roles  in  the  organization’s  set 
of  standard  processes. 

5.  Document  the  training  needed  to  maintain  the  safe,  secure,  and 
continued  operation  of  the  business. 

6.  Revise  the  organization’s  strategic  needs  and  required  training  as 
necessary. 
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SP  1 .2  Determine  Which  T raining  Needs  Are  the  Responsibiiity  of  the 
Organization 

Determine  which  training  needs  are  the  responsibiiity  of  the 
organization  and  which  are  ieft  to  the  individuai  project  or  support 
group. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  needed  knowledge  and  skills. 

In  addition  to  strategic  training  needs,  organizational  training  addresses 
training  requirements  that  are  common  across  projects  and  support  groups. 
Projects  and  support  groups  have  the  primary  responsibility  for  identifying 
and  addressing  their  training  needs.  The  organization’s  training  staff  is 
responsible  for  addressing  only  common  cross-project  and  support  group 
training  needs  (e.g.,  training  in  work  environments  common  to  multiple 
projects).  In  some  cases,  however,  the  organization’s  training  staff  may 
address  additional  training  needs  of  projects  and  support  groups,  as 
negotiated  with  them,  in  the  context  of  the  training  resources  available  and 
the  organization’s  training  priorities. 

Example  Work  Products 

1 .  Common  project  and  support  group  training  needs 

2.  Training  commitments 
Subpractices 

1 .  Analyze  the  training  needs  identified  by  projects  and  support  groups. 

Analysis  of  project  and  support  group  needs  is  intended  to  identify  common  training 
needs  that  can  be  most  efficiently  addressed  organization  wide.  These  needs  analysis 
activities  are  used  to  anticipate  future  training  needs  that  are  first  visible  at  the  project 
and  support  group  level. 

2.  Negotiate  with  projects  and  support  groups  on  how  their  training  needs 
will  be  satisfied. 

The  support  provided  by  the  organization’s  training  staff  depends  on  the  training 
resources  available  and  the  organization’s  training  priorities. 

I  Examples  of  training  appropriately  performed  by  the  project  or  support  group  include 
;  the  following: 

;  •  Training  in  the  application  or  service  domain  of  the  project 
I  •  Training  in  the  unique  tools  and  methods  used  by  the  project  or  support  group 
I  •  Training  in  safety,  security,  and  human  factors 

3.  Document  commitments  for  providing  training  support  to  projects  and 
support  groups. 

SP  1.3  Establish  an  Organizational  Training  Tactical  Plan 

Establish  and  maintain  an  organizational  training  tactical  plan. 

The  organizational  training  tactical  plan  is  the  plan  to  deliver  the  training 
that  is  the  responsibility  of  the  organization  and  is  necessary  for  individuals 
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to  perform  their  roles  effectively.  This  plan  addresses  the  near-term 
execution  of  training  and  is  adjusted  periodically  in  response  to  changes 
(e.g.,  in  needs,  in  resources)  and  to  evaluations  of  effectiveness. 

Example  Work  Products 

1 .  Organizational  training  tactical  plan 

Subpractices 

1.  Establish  the  content  of  the  plan. 

i  Organizational  training  tactical  plans  typically  contain  the  following: 

;  •  Training  needs 
;  •  Training  topics 

i  •  Schedules  based  on  training  activities  and  their  dependencies 
i  •  Methods  used  for  training 

I  •  Requirements  and  quality  standards  for  training  materials 
I  •  Training  tasks,  roles,  and  responsibilities 

;  •  Required  resources  Including  tools,  facilities,  environments,  staffing,  skills,  and 
I  knowledge 

2.  Establish  commitments  to  the  plan. 

Documented  commitments  by  those  who  are  responsible  for  implementing  and 
supporting  the  plan  are  essential  for  the  plan  to  be  effective. 

3.  Revise  the  plan  and  commitments  as  necessary. 

SP  1 .4  Establish  a  T raining  Capability 

Establish  and  maintain  a  training  capability  to  address 
organizational  training  needs. 

Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai  evaiuation 
process  that  evaiuates  identified  aiternatives  against  estabiished  criteria. 

Example  Work  Products 

1 .  Training  materials  and  supporting  artifacts 
Subpractices 

1 .  Select  appropriate  approaches  to  satisfy  organizational  training  needs. 

Many  factors  may  affect  the  selection  of  training  approaches,  including  audience 
specific  knowledge,  costs,  schedule,  and  the  work  environment.  Selecting  an  approach 
requires  consideration  of  the  means  to  provide  skills  and  knowledge  in  the  most 
effective  way  possible  given  the  constraints. 
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Examples  of  training  approaches  include  the  following: 

•  Classroom  training 

•  Computer  aided  instruction 

•  Guided  self  study 

•  Formal  apprenticeship  and  mentoring  programs 

•  Facilitated  videos 

•  Chalk  talks 

•  Brown  bag  lunch  seminars 

•  Structured  on-the-job  training 


2.  Determine  whether  to  develop  training  materials  internally  or  to  acquire 
them  externally. 

Determine  the  costs  and  benefits  of  internal  training  development  and  of  acquiring 
training  externally. 

:  Example  criteria  that  can  be  used  to  determine  the  most  effective  mode  of  knowledge 
i  or  skill  acquisition  include  the  following: 

i  •  Applicability  to  work  or  process  performance  objectives 
;  •  Availability  of  time  to  prepare  for  project  execution 
;  •  Applicability  to  business  objectives 
i  •  Availability  of  in-house  expertise 
i  •  Availability  of  training  from  external  sources 


Examples  of  external  sources  of  training  include  the  following: 

•  Customer  provided  training 

•  Commercially  available  training  courses 

•  Academic  programs 

•  Professional  conferences 

•  Seminars 


3.  Develop  or  obtain  training  materials. 

Training  can  be  provided  by  the  project,  support  groups,  the  organization,  or  an 
external  organization.  The  organization’s  training  staff  coordinates  the  acquisition  and 
delivery  of  training  regardless  of  its  source. 

i  Examples  of  training  materials  include  the  following: 

i  •  Courses 

i  •  Computer-aided  instruction 
;  •  Videos 


4.  Develop  or  obtain  qualified  instructors,  instructional  designers,  or 
mentors. 

To  ensure  that  those  who  develop  and  deliver  internal  training  have  the  necessary 
knowledge  and  training  skills,  criteria  can  be  defined  to  identify,  develop,  and  qualify 
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them.  The  development  of  training,  including  self  study  and  online  training,  should 
involve  those  who  have  experience  in  instructional  design.  In  the  case  of  external 
training,  the  organization’s  training  staff  can  investigate  how  the  training  provider 
determines  which  instructors  will  deliver  the  training.  This  selection  of  qualified 
instructors  can  also  be  a  factor  in  selecting  or  continuing  to  use  a  training  provider. 

5.  Describe  the  training  in  the  organization’s  training  curriculum. 

;  Examples  of  the  information  provided  in  training  descriptions  for  each  course  include 
:  the  following: 

i  •  Topics  covered  in  the  training 
i  •  Intended  audience 

i  •  Prerequisites  and  preparation  for  participating 

;  •  Training  objectives 

;  •  Length  of  the  training 

i  •  Lesson  plans 

i  •  Completion  criteria  for  the  course 

I  •  Criteria  for  granting  training  waivers 

6.  Revise  training  materials  and  supporting  artifacts  as  necessary. 

;  Examples  of  situations  in  which  training  materials  and  supporting  artifacts  may  need  to 
i  be  revised  include  the  following: 

i  •  Training  needs  change  (e.g.,  when  new  technology  associated  with  the  training  topic  is 

;  available) 

i  •  An  evaluation  of  the  training  identifies  the  need  for  change  (e.g.,  evaluations  of  training 
;  effectiveness  surveys,  training  program  performance  assessments,  instructor 

;  evaluation  forms) 


SG  2  Provide  Training 

Training  for  indi  vidua  is  to  perform  their  roies  effectiveiy  is  provided. 

When  selecting  people  to  be  trained,  the  following  should  be  considered: 

•  Background  of  the  target  population  of  training  participants 

•  Prerequisite  background  to  receive  training 

•  Skills  and  abilities  needed  by  people  to  perform  their  roles 

•  Need  for  cross-discipline  training  for  all  disciplines,  including  project 
management 

•  Need  for  managers  to  have  training  in  appropriate  organizational 
processes 

•  Need  for  training  in  basic  principles  of  all  appropriate  disciplines  or 
services  to  support  staff  in  quality  management,  configuration 
management,  and  other  related  support  functions 

•  Need  to  provide  competency  development  for  critical  functional  areas 

•  Need  to  maintain  competencies  and  qualifications  of  staff  to  operate 
and  maintain  work  environments  common  to  multiple  projects 
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SP  2.1  Deliver  Training 

Deliver  training  following  the  organizational  training  tactical  plan. 

Example  Work  Products 

1 .  Delivered  training  course 

Subpractices 

1 .  Select  those  who  will  receive  the  training  necessary  to  perform  their 
roles  effectively. 

Training  is  intended  to  impart  knowledge  and  skills  to  people  performing  various  roles 
in  the  organization.  Some  people  already  possess  the  knowledge  and  skills  required  to 
perform  well  in  their  designated  roles.  Training  can  be  waived  for  these  people,  but 
care  should  be  taken  that  training  waivers  are  not  abused. 

2.  Schedule  the  training,  including  any  resources,  as  necessary  (e.g., 
facilities,  instructors). 

Training  should  be  planned  and  scheduled.  Training  is  provided  that  has  a  direct 
bearing  on  work  performance  expectations.  Therefore,  optimal  training  occurs  in  a 
timely  manner  with  regard  to  imminent  job  performance  expectations. 

:  These  performance  expectations  often  include  the  following: 

i  •  Training  in  the  use  of  specialized  tools 

[  •  Training  in  procedures  that  are  new  to  the  person  who  will  perform  them 

3.  Deliver  the  training. 

If  the  training  is  delivered  by  a  person,  then  appropriate  training  professionals  (e.g., 
experienced  instructors,  mentors)  should  deliver  the  training.  When  possible,  training 
is  delivered  in  settings  that  closely  resemble  the  actual  work  environment  and  includes 
activities  to  simulate  actual  work  situations.  This  approach  includes  integration  of  tools, 
methods,  and  procedures  for  competency  development.  Training  is  tied  to  work 
responsibilities  so  that  on-the-job  activities  or  other  outside  experiences  will  reinforce 
the  training  within  a  reasonable  time  after  the  training  was  delivered. 

4.  Track  the  delivery  of  training  against  the  plan. 

SP  2.2  Establish  Training  Records 

Establish  and  maintain  records  of  organizational  training. 

This  practice  applies  to  the  training  performed  at  the  organizational  level. 
Establishment  and  maintenance  of  training  records  for  project  or  support 
group  sponsored  training  is  the  responsibility  of  each  individual  project  or 
support  group. 

Example  Work  Products 

1.  Training  records 

2.  Training  updates  to  the  organizational  repository 
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Subpractices 

1 .  Keep  records  of  all  students  who  successfully  complete  each  training 
course  or  other  approved  training  activity  as  well  as  those  who  are 
unsuccessful. 

2.  Keep  records  of  all  staff  who  are  waived  from  training. 

The  rationale  for  granting  a  waiver  should  be  documented,  and  both  the  manager 
responsible  and  the  manager  of  the  excepted  individual  should  approve  the  waiver. 

3.  Keep  records  of  all  students  who  successfully  complete  their  required 
training. 

4.  Make  training  records  available  to  the  appropriate  people  for 
consideration  in  assignments. 

Training  records  may  be  part  of  a  skills  matrix  developed  by  the  training  organization 
to  provide  a  summary  of  the  experience  and  education  of  people,  as  well  as  training 
sponsored  by  the  organization. 

SP  2.3  Assess  Training  Effectiveness 

Assess  the  effectiveness  of  the  organization’s  training  program. 

A  process  should  exist  to  determine  the  effectiveness  of  training  (i.e.,  how 

well  training  is  meeting  the  organization’s  needs). 

- - - - - - - - - - - - 

I  Examples  of  methods  used  to  assess  training  effectiveness  include  the  following: 

I  •  Testing  in  the  training  context 
;  •  Post-training  surveys  of  training  participants 
i  •  Surveys  of  manager  satisfaction  with  post-training  effects 
;  •  Assessment  mechanisms  embedded  in  courseware 


Measures  can  be  taken  to  assess  the  benefits  of  training  against  both  the 
project’s  and  organization’s  objectives.  Particular  attention  should  be  paid 
to  the  need  for  various  training  methods,  such  as  training  teams  as  integral 
work  units.  When  used,  work  or  process  performance  objectives  should  be 
unambiguous,  observable,  verifiable,  and  shared  with  course  participants. 
The  results  of  the  training  effectiveness  assessment  should  be  used  to 
revise  training  materials  as  described  in  the  Establish  a  Training  Capability 
specific  practice. 

Example  Work  Products 

1 .  Training  effectiveness  surveys 

2.  Training  program  performance  assessments 

3.  Instructor  evaluation  forms 

4.  Training  examinations 
Subpractices 

1 .  Assess  in-progress  or  completed  projects  to  determine  whether  staff 
knowledge  is  adequate  for  performing  project  tasks. 
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2.  Provide  a  mechanism  for  assessing  the  effectiveness  of  each  training 
course  with  respect  to  established  organizational,  project,  or  individual 
learning  (or  performance)  objectives. 

3.  Obtain  student  evaluations  of  how  well  training  activities  met  their 
needs. 
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PRODUCT  INTEGRATION 


An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Product  Integration  (PI)  is  to  assemble  the  product  from  the 
product  components,  ensure  that  the  product,  as  integrated,  behaves 
properly  (i.e.,  possesses  the  required  functionality  and  quality  attributes), 
and  deliver  the  product. 


Introductory  Notes 


This  process  area  addresses  the  integration  of  product  components  into 
more  complex  product  components  or  into  complete  products. 

The  scope  of  this  process  area  is  to  achieve  complete  product  integration 
through  progressive  assembly  of  product  components,  in  one  stage  or  in 
incremental  stages,  according  to  a  defined  integration  strategy  and 
procedures.  Throughout  the  process  areas,  where  the  terms  “product”  and 
“product  component”  are  used,  their  intended  meanings  also  encompass 
services,  service  systems,  and  their  components. 

A  critical  aspect  of  product  integration  is  the  management  of  internal  and 
external  interfaces  of  the  products  and  product  components  to  ensure 
compatibility  among  the  interfaces.  These  interfaces  are  not  limited  to  user 
interfaces,  but  also  apply  to  interfaces  among  components  of  the  product, 
including  internal  and  external  data  sources,  middleware,  and  other 
components  that  may  or  may  not  be  within  the  development  organization’s 
control  but  on  which  the  product  relies.  Attention  should  be  paid  to  interface 
management  throughout  the  project. 

Product  integration  is  more  than  just  a  one-time  assembly  of  the  product 
components  at  the  conclusion  of  design  and  fabrication.  Product  integration 
can  be  conducted  incrementally,  using  an  iterative  process  of  assembling 
product  components,  evaluating  them,  and  then  assembling  more  product 
components.  It  can  be  conducted  using  highly  automated  builds  and 
continuous  integration  of  the  completed  unit  tested  product.  This  process 
can  begin  with  analysis  and  simulations  (e.g.,  threads,  rapid  prototypes, 
virtual  prototypes,  physical  prototypes)  and  steadily  progress  through 
increasingly  more  realistic  increments  until  the  final  product  is  achieved.  In 
each  successive  build,  prototypes  (virtual,  rapid,  or  physical)  are 
constructed,  evaluated,  improved,  and  reconstructed  based  on  knowledge 
gained  in  the  evaluation  process.  The  degree  of  virtual  versus  physical 
prototyping  required  depends  on  the  functionality  of  the  design  tools,  the 
complexity  of  the  product,  and  its  associated  risk.  There  is  a  high  probability 
that  the  product,  integrated  in  this  manner,  will  pass  product  verification  and 
validation.  For  some  products  and  services,  the  last  integration  phase  will 
occur  when  they  are  deployed  at  the  intended  operational  site. 


Product  Integration  (PI) 


257 


CMMI  for  Development,  Version  1.3 


For  product  lines,  products  are  assembled  according  to  the  product  line 
production  plan.  The  product  line  production  plan  specifies  the  assembly 
process,  including  which  core  assets  to  use  and  how  product  line  variation 
is  resolved  within  those  core  assets. 

f................ - - - - 

;  In  Agile  environments,  product  integration  is  a  frequent,  often  daily,  activity.  For  example,  for 
i  software,  working  code  is  continuously  added  to  the  code  base  in  a  process  called 
I  ‘‘continuous  integration.”  In  addition  to  addressing  continuous  integration,  the  product 
;  integration  strategy  can  address  how  supplier  supplied  components  will  be  incorporated, 
i  how  functionality  will  be  built  (in  layers  vs.  ‘‘vertical  slices”),  and  when  to  “refactor.”  The 
I  strategy  should  be  established  early  in  the  project  and  be  revised  to  reflect  evolving  and 
i  emerging  component  interfaces,  external  feeds,  data  exchange,  and  application  program 
i  interfaces.  (See  “Interpreting  CMMI  When  Using  Agile  Approaches”  in  Part  I.) 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more  information 
about  identifying  interface  requirements. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
designing  interfaces  using  criteria. 

Refer  to  the  Validation  process  area  for  more  information  about  performing 
validation. 

Refer  to  the  Verification  process  area  for  more  information  about  performing 
verification. 

Refer  to  the  Configuration  Management  process  area  for  more  information 
about  tracking  and  controlling  changes. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  analyzing  possible  decisions  using  a  formal  evaluation 
process  that  evaluates  identified  alternatives  against  established  criteria. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  risks  and  mitigating  risks. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  managing  the  acquisition  of  products  and  services  from 
suppliers. 
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Specific  Goai  and  Practice  Summary 

SG  1  Prepare  for  Product  Integration 

SP  1 .1  Establish  an  Integration  Strategy 

SP  1 .2  Establish  the  Produot  Integration  Environment 

SP  1 .3  Establish  Product  Integration  Procedures  and  Criteria 

SG  2  Ensure  Interface  Compatibility 

SP  2.1  Review  Interface  Descriptions  for  Completeness 

SP  2.2  Manage  Interfaces 

SG  3  Assemble  Product  Components  and  Deliver  the  Product 

SP  3.1  Confirm  Readiness  of  Product  Components  for  Integration 

SP  3.2  Assemble  Product  Components 

SP  3.3  Evaluate  Assembled  Product  Components 

SP  3.4  Package  and  Deliver  the  Product  or  Product  Component 

Specific  Practices  by  Goai 


SG  1 _ Prepare  for  Product  Integration _ 

Preparation  for  product  integration  is  conducted. 

Preparing  for  the  integration  of  product  components  involves  establishing 
an  integration  strategy,  establishing  the  environment  for  performing  the 
integration,  and  establishing  integration  procedures  and  criteria. 
Preparation  for  integration  starts  early  in  the  project. 

SP  1.1  Establish  an  Integration  Strategy 

Estabiish  and  maintain  a  product  integration  strategy. 

The  product  integration  strategy  describes  the  approach  for  receiving, 
assembling,  and  evaluating  the  product  components  that  comprise  the 
product. 

A  product  integration  strategy  addresses  items  such  as  the  following: 

•  Making  product  components  available  for  integration  (e.g.,  in  what 
sequence) 

•  Assembling  and  evaluating  as  a  single  build  or  as  a  progression  of 
incremental  builds 

•  Including  and  testing  features  in  each  iteration  when  using  iterative 
development 

•  Managing  interfaces 

•  Using  models,  prototypes,  and  simulations  to  assist  in  evaluating  an 
assembly,  including  its  interfaces 

•  Establishing  the  product  integration  environment 

•  Defining  procedures  and  criteria 

•  Making  available  the  appropriate  test  tools  and  equipment 

•  Managing  product  hierarchy,  architecture,  and  complexity 

•  Recording  results  of  evaluations 

•  Handling  exceptions 
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The  integration  strategy  should  also  be  aligned  with  the  technical  approach 
described  in  the  Project  Planning  process  area  and  harmonized  with  the 
selection  of  solutions  and  the  design  of  product  and  product  components  in 
the  Technical  Solution  process  area. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
selecting  product  component  solutions  and  implementing  the  design. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  analyzing  possible  decisions  using  a  formal  evaluation 
process  that  evaluates  identified  alternatives  against  established  criteria. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  and  maintaining  plans  that  define  project  activities. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  risks  and  mitigating  risks. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  managing  the  acquisition  of  products  and  services  from 
suppliers. 

The  results  of  developing  a  product  integration  strategy  are  typically 
documented  in  a  product  integration  plan,  which  is  reviewed  with 
stakeholders  to  promote  commitment  and  understanding.  Some  of  the 
items  addressed  in  a  product  integration  strategy  are  covered  in  more  detail 
in  the  other  specific  practices  and  generic  practices  of  this  process  area 
(e.g.,  environment,  procedures  and  criteria,  training,  roles  and 
responsibilities,  involvement  of  relevant  stakeholders). 

Example  Work  Products 

1 .  Product  integration  strategy 

2.  Rationale  for  selecting  or  rejecting  alternative  product  integration 
strategies 

Subpractices 

1 .  Identify  the  product  components  to  be  integrated. 

2.  Identify  the  verifications  to  be  performed  during  the  integration  of  the 
product  components. 

This  identification  includes  verifications  to  be  performed  on  interfaces. 

3.  Identify  alternative  product  component  integration  strategies. 

Developing  an  integration  strategy  can  involve  specifying  and  evaluating  several 
alternative  integration  strategies  or  sequences. 

4.  Select  the  best  integration  strategy. 

The  availability  of  the  following  will  need  to  be  aligned  or  harmonized  with  the 
integration  strategy:  product  components;  the  integration  environment;  test  tools  and 
equipment;  procedures  and  criteria;  relevant  stakeholders;  and  staff  who  possess  the 
appropriate  skills. 
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5.  Periodically  review  the  product  integration  strategy  and  revise  as 
needed. 

Assess  the  product  integration  strategy  to  ensure  that  variations  in  production  and 
delivery  schedules  have  not  had  an  adverse  impact  on  the  integration  sequence  or 
compromised  the  factors  on  which  earlier  decisions  were  made. 

6.  Record  the  rationale  for  decisions  made  and  deferred. 

SP  1.2  Establish  the  Product  Integration  Environment 

Establish  and  maintain  the  environment  needed  to  support  the 
integration  of  the  product  components. 

The  environment  for  product  integration  can  either  be  acquired  or 
developed.  To  establish  an  environment,  requirements  for  the  purchase  or 
development  of  equipment,  software,  or  other  resources  will  need  to  be 
developed.  These  requirements  are  gathered  when  implementing  the 
processes  associated  with  the  Requirements  Development  process  area. 
The  product  integration  environment  can  include  the  reuse  of  existing 
organizational  resources.  The  decision  to  acquire  or  develop  the  product 
integration  environment  is  addressed  in  the  processes  associated  with  the 
Technical  Solution  process  area. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
performing  make,  buy,  or  reuse  analyses. 

The  environment  required  at  each  step  of  the  product  integration  process 
can  include  test  equipment,  simulators  (taking  the  place  of  unavailable 
product  components),  pieces  of  real  equipment,  and  recording  devices. 

Example  Work  Products 

1 .  Verified  environment  for  product  integration 

2.  Support  documentation  for  the  product  integration  environment 

Subpractices 

1 .  Identify  the  requirements  for  the  product  integration  environment. 

2.  Identify  verification  procedures  and  criteria  for  the  product  integration 
environment. 

3.  Decide  whether  to  make  or  buy  the  needed  product  integration 
environment. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  managing  the  acquisition  of  products  and  services 
from  suppliers. 

4.  Develop  an  integration  environment  if  a  suitable  environment  cannot 
be  acquired. 

For  unprecedented,  complex  projects,  the  product  integration  environment  can  be  a 
major  development.  As  such,  it  would  involve  project  planning,  requirements 
development,  technical  solutions,  verification,  validation,  and  risk  management. 

5.  Maintain  the  product  integration  environment  throughout  the  project. 

6.  Dispose  of  those  portions  of  the  environment  that  are  no  longer  useful. 
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SP  1.3  Establish  Product  Integration  Procedures  and  Criteria 

Establish  and  maintain  procedures  and  criteria  for  integration  of 
the  product  components. 

Procedures  for  the  integration  of  the  product  components  can  include  such 
things  as  the  number  of  incremental  iterations  to  be  performed  and  details 
of  the  expected  tests  and  other  evaluations  to  be  carried  out  at  each  stage. 

Criteria  can  indicate  the  readiness  of  a  product  component  for  integration  or 
its  acceptability. 

Procedures  and  criteria  for  product  integration  address  the  following: 

•  Level  of  testing  for  build  components 

•  Verification  of  interfaces 

•  Thresholds  of  performance  deviation 

•  Derived  requirements  for  the  assembly  and  its  external  interfaces 

•  Allowable  substitutions  of  components 

•  Testing  environment  parameters 

•  Limits  on  cost  of  testing 

•  Quality/cost  tradeoffs  for  integration  operations 

•  Probability  of  proper  functioning 

•  Delivery  rate  and  its  variation 

•  Lead  time  from  order  to  delivery 

•  Staff  member  availability 

•  Availability  of  the  integration  facility/line/environment 

Criteria  can  be  defined  for  how  the  product  components  are  to  be  verified 
and  the  behaviors  (functionality  and  quality  attributes)  they  are  expected  to 
have.  Criteria  can  be  defined  for  how  the  assembled  product  components 
and  final  integrated  product  are  to  be  validated  and  delivered. 

Criteria  can  also  constrain  the  degree  of  simulation  permitted  for  a  product 
component  to  pass  a  test,  or  can  constrain  the  environment  to  be  used  for 
the  integration  test. 

Pertinent  parts  of  the  schedule  and  criteria  for  assembly  should  be  shared 
with  suppliers  of  work  products  to  reduce  the  occurrence  of  delays  and 
component  failure. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  executing  the  supplier  agreement. 

Example  Work  Products 

1 .  Product  integration  procedures 

2.  Product  integration  criteria 
Subpractices 

1 .  Establish  and  maintain  product  integration  procedures  for  the  product 
components. 
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2.  Establish  and  maintain  criteria  for  product  component  integration  and 
evaluation. 

3.  Establish  and  maintain  criteria  for  validation  and  delivery  of  the 
integrated  product. 

SG  2 _ Ensure  Interface  Compatibility _ 

The  product  component  interfaces,  both  internal  and  external,  are  compatible. 

Many  product  integration  problems  arise  from  unknown  or  uncontrolled 
aspects  of  both  internal  and  external  interfaces.  Effective  management  of 
product  component  interface  requirements,  specifications,  and  designs 
helps  ensure  that  implemented  interfaces  will  be  complete  and  compatible. 

SP  2.1  Review  Interface  Descriptions  for  Completeness 

Review  interface  descriptions  for  coverage  and  completeness. 

The  interfaces  should  include,  in  addition  to  product  component  interfaces, 
all  the  interfaces  with  the  product  integration  environment. 

Example  Work  Products 

1 .  Categories  of  interfaces 

2.  List  of  interfaces  per  category 

3.  Mapping  of  the  interfaces  to  the  product  components  and  the  product 
integration  environment 

Subpractices 

1 .  Review  interface  data  for  completeness  and  ensure  complete  coverage 
of  all  interfaces. 

Consider  all  the  product  components  and  prepare  a  relationship  table.  Interfaces  are 
usually  classified  in  three  main  classes:  environmental,  physical,  and  functional. 

Typical  categories  for  these  classes  include  the  following:  mechanical,  fluid,  sound, 
electrical,  climatic,  electromagnetic,  thermal,  message,  and  the  human-machine  or 
human  interface. 
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Examples  of  interfaces  (e.g.,  for  mechanical  or  electronic  components)  that  can  be 

classified  within  these  three  classes  include  the  following: 

•  Mechanical  interfaces  (e.g.,  weight  and  size,  center  of  gravity,  clearance  of  parts  in 
operation,  space  required  for  maintenance,  fixed  links,  mobile  links,  shocks  and 
vibrations  received  from  the  bearing  structure) 

•  Noise  interfaces  (e.g.,  noise  transmitted  by  the  structure,  noise  transmitted  in  the  air, 
acoustics) 

•  Climatic  interfaces  (e.g.,  temperature,  humidity,  pressure,  salinity) 

•  Thermal  interfaces  (e.g.,  heat  dissipation,  transmission  of  heat  to  the  bearing  structure, 
air  conditioning  characteristics) 

•  Fluid  interfaces  (e.g.,  fresh  water  inlet/outlet,  seawater  inlet/outlet  for  a  naval/coastal 
product,  air  conditioning,  compressed  air,  nitrogen,  fuel,  lubricating  oil,  exhaust  gas 
outlet) 

•  Electrical  interfaces  (e.g.,  power  supply  consumption  by  network  with  transients  and 
peak  values;  nonsensitive  control  signal  for  power  supply  and  communications; 
sensitive  signal  [e.g.,  analog  links];  disturbing  signal  [e.g.,  microwave);  grounding 
signal  to  comply  with  the  TEMPEST  standard) 

•  Electromagnetic  interfaces  (e.g.,  magnetic  field,  radio  and  radar  links,  optical  band  link 
wave  guides,  coaxial  and  optical  fibers) 

•  Human-machine  interface  (e.g.,  audio  or  voice  synthesis,  audio  or  voice  recognition, 
display  [analog  dial,  liquid  crystal  display,  indicators'  light  emitting  diodes],  manual 
controls  [pedal,  [oystick,  track  ball,  keyboard,  push  buttons,  touch  screen]) 

•  Message  interfaces  (e.g.,  origination,  destination,  stimulus,  protocols,  data 
characteristics) 


2.  Ensure  that  product  components  and  interfaces  are  marked  to  ensure 
easy  and  correct  connection  to  the  joining  product  component. 

3.  Periodically  review  the  adequacy  of  interface  descriptions. 

Once  established,  the  interface  descriptions  should  be  periodically  reviewed  to  ensure 
there  is  no  deviation  between  the  existing  descriptions  and  the  products  being 
developed,  processed,  produced,  or  bought. 

The  interface  descriptions  for  product  components  should  be  reviewed  with  relevant 
stakeholders  to  avoid  misinterpretations,  reduce  delays,  and  prevent  the  development 
of  interfaces  that  do  not  work  properly. 

SP  2.2  Manage  Interfaces 

Manage  internal  and  external  Interface  definitions,  designs,  and 
changes  for  products  and  product  components. 

Interface  requirements  drive  the  development  of  the  interfaces  necessary  to 
integrate  product  components.  Managing  product  and  product  component 
interfaces  starts  early  in  the  development  of  the  product.  The  definitions 
and  designs  for  interfaces  affect  not  only  the  product  components  and 
external  systems,  but  can  also  affect  the  verification  and  validation 
environments. 

Refer  to  the  Requirements  Development  process  area  for  more  information 
about  identifying  interface  requirements. 
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Refer  to  the  Technical  Solution  process  area  for  more  information  about 
designing  interfaces  using  criteria. 

Refer  to  the  Configuration  Management  process  area  for  more  information 
about  establishing  and  maintaining  the  integrity  of  work  products  using 
configuration  identification,  configuration  control,  configuration  status 
accounting,  and  configuration  audits. 

Refer  to  the  Manage  Requirements  Changes  specific  practice  in  the 
Requirements  Management  process  area  for  more  information  about 
managing  the  changes  to  the  interface  requirements. 

Management  of  the  interfaces  includes  maintenance  of  the  consistency  of 
the  interfaces  throughout  the  life  of  the  product,  compliance  with 
architectural  decisions  and  constraints,  and  resolution  of  conflict, 
noncompliance,  and  change  issues.  The  management  of  interfaces 
between  products  acquired  from  suppliers  and  other  products  or  product 
components  is  critical  for  success  of  the  project. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  managing  the  acquisition  of  products  and  services  from 
suppliers. 

The  interfaces  should  include,  in  addition  to  product  component  interfaces, 
all  the  interfaces  with  the  environment  as  well  as  other  environments  for 
verification,  validation,  operations,  and  support. 

The  interface  changes  are  documented,  maintained,  and  readily  accessible. 

Example  Work  Products 

1 .  Table  of  relationships  among  the  product  components  and  the  external 
environment  (e.g.,  main  power  supply,  fastening  product,  computer  bus 
system) 

2.  Table  of  relationships  among  the  different  product  components 

3.  List  of  agreed-to  interfaces  defined  for  each  pair  of  product 
components,  when  applicable 

4.  Reports  from  the  interface  control  working  group  meetings 

5.  Action  items  for  updating  interfaces 

6.  Application  program  interface  (API) 

7.  Updated  interface  description  or  agreement 
Subpractices 

1 .  Ensure  the  compatibility  of  the  interfaces  throughout  the  life  of  the 
product. 

2.  Resolve  conflict,  noncompliance,  and  change  issues. 

3.  Maintain  a  repository  for  interface  data  accessible  to  project 
participants. 
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A  common  accessible  repository  for  interface  data  provides  a  mechanism  to  ensure 
that  everyone  knows  where  the  current  interface  data  reside  and  can  access  them  for 
use. 

SG  3  Assemble  Product  Components  and  Deliver  the  Product 

Verified  product  components  are  assembied  and  the  integrated,  verified,  and 
vaiidated  product  is  deiivered. 

Integration  of  product  components  proceeds  according  to  the  product 
integration  strategy  and  procedures.  Before  integration,  each  product 
component  should  be  confirmed  to  be  compliant  with  its  interface 
requirements.  Product  components  are  assembled  into  larger,  more 
complex  product  components.  These  assembled  product  components  are 
checked  for  correct  interoperation.  This  process  continues  until  product 
integration  is  complete.  If,  during  this  process,  problems  are  identified,  the 
problem  should  be  documented  and  a  corrective  action  process  initiated. 

The  timely  receipt  of  needed  product  components  and  the  involvement  of 
the  right  people  contribute  to  the  successful  integration  of  the  product 
components  that  compose  the  product. 

SP  3.1  Confirm  Readiness  of  Product  Components  for  Integration 

Confirm,  prior  to  assembiy,  that  each  product  component  required 
to  assembie  the  product  has  been  property  identified,  behaves 
according  to  its  description,  and  that  the  product  component 
interfaces  compiy  with  the  interface  descriptions. 

Refer  to  the  Verification  process  area  for  more  information  about  performing 
verification. 

The  purpose  of  this  specific  practice  is  to  ensure  that  the  properly  identified 
product  component  that  meets  its  description  can  actually  be  assembled 
according  to  the  product  integration  strategy  and  procedures.  The  product 
components  are  checked  for  quantity,  obvious  damage,  and  consistency 
between  the  product  component  and  interface  descriptions. 

Those  who  conduct  product  integration  are  ultimately  responsible  for 
checking  to  make  sure  everything  is  proper  with  the  product  components 
before  assembly. 

Example  Work  Products 

1 .  Acceptance  documents  for  the  received  product  components 

2.  Delivery  receipts 

3.  Checked  packing  lists 

4.  Exception  reports 

5.  Waivers 

Subpractices 

1 .  Track  the  status  of  all  product  components  as  soon  as  they  become 
available  for  integration. 
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2.  Ensure  that  product  components  are  delivered  to  the  product 
integration  environment  in  accordance  with  the  product  integration 
strategy  and  procedures. 

3.  Confirm  the  receipt  of  each  properly  identified  product  component. 

4.  Ensure  that  each  received  product  component  meets  its  description. 

5.  Check  the  configuration  status  against  the  expected  configuration. 

6.  Perform  a  pre-check  (e.g.,  by  a  visual  inspection,  using  basic 
measures)  of  all  the  physical  interfaces  before  connecting  product 
components  together. 

SP  3.2  Assemble  Product  Components 

Assemble  product  components  according  to  the  product 
integration  strategy  and  procedures. 

The  assembly  activities  of  this  specific  practice  and  the  evaluation  activities 
of  the  next  specific  practice  are  conducted  iteratively,  from  the  initial  product 
components,  through  the  interim  assemblies  of  product  components,  to  the 
product  as  a  whole. 

Example  Work  Products 

1 .  Assembled  product  or  product  components 
Subpractices 

1 .  Ensure  the  readiness  of  the  product  integration  environment. 

2.  Conduct  integration  in  accordance  with  the  product  integration 
strategy,  procedures,  and  criteria. 

Record  all  appropriate  information  (e.g.,  configuration  status,  serial  numbers  of  the 
product  components,  types,  calibration  date  of  the  meters). 

3.  Revise  the  product  integration  strategy,  procedures,  and  criteria  as 
appropriate. 

SP  3.3  Evaluate  Assembled  Product  Components 

Evaluate  assembled  product  components  for  interface 
compatibility. 

Refer  to  the  Validation  process  area  for  more  information  about  performing 
validation. 

Refer  to  the  Verification  process  area  for  more  information  about  performing 
verification. 

This  evaluation  involves  examining  and  testing  assembled  product 
components  for  performance,  suitability,  or  readiness  using  the  product 
integration  procedures,  criteria,  and  environment.  It  is  performed  as 
appropriate  for  different  stages  of  assembly  of  product  components  as 
identified  in  the  product  integration  strategy  and  procedures.  The  product 
integration  strategy  and  procedures  can  define  a  more  refined  integration 
and  evaluation  sequence  than  might  be  envisioned  just  by  examining  the 
product  hierarchy  or  architecture.  For  example,  if  an  assembly  of  product 
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components  is  composed  of  four  less  complex  product  components,  the 
integration  strategy  will  not  necessarily  call  for  the  simultaneous  integration 
and  evaluation  of  the  four  units  as  one.  Rather,  the  four  less  complex  units 
can  be  integrated  progressively,  one  at  a  time,  with  an  evaluation  after  each 
assembly  operation  prior  to  realizing  the  more  complex  product  component 
that  matched  the  specification  in  the  product  architecture.  Alternatively,  the 
product  integration  strategy  and  procedures  could  have  determined  that 
only  a  final  evaluation  was  the  best  one  to  perform. 

Example  Work  Products 

1 .  Exception  reports 

2.  Interface  evaluation  reports 

3.  Product  integration  summary  reports 
Subpractices 

1 .  Conduct  the  evaluation  of  assembled  product  components  following 
the  product  integration  strategy,  procedures,  and  criteria. 

2.  Record  the  evaluation  results. 

:  Example  results  Include  the  following: 

i  •  Any  adaptation  required  to  the  Integration  procedure  or  criteria 
i  •  Any  change  to  the  product  configuration  (spare  parts,  new  release) 
i  •  Evaluation  procedure  or  criteria  deviations 


SP  3.4  Package  and  Deliver  the  Product  or  Product  Component 

Package  the  assembled  product  or  product  component  and  deliver 
it  to  the  customer. 

Refer  to  the  Validation  process  area  for  more  information  about  performing 
validation. 

Refer  to  the  Verification  process  area  for  more  information  about  performing 
verification. 

The  packaging  requirements  for  some  products  can  be  addressed  in  their 
specifications  and  verification  criteria.  This  handling  of  requirements  is 
especially  important  when  items  are  stored  and  transported  by  the 
customer.  In  such  cases,  there  can  be  a  spectrum  of  environmental  and 
stress  conditions  specified  for  the  package.  In  other  circumstances,  factors 
such  as  the  following  can  become  important: 

•  Economy  and  ease  of  transportation  (e.g.,  containerization) 

•  Accountability  (e.g.,  shrink  wrapping) 

•  Ease  and  safety  of  unpacking  (e.g.,  sharp  edges,  strength  of  binding 
methods,  childproofing,  environmental  friendliness  of  packing  material, 
weight) 

The  adjustment  required  to  fit  product  components  together  in  the  factory 
could  be  different  from  the  one  required  to  fit  product  components  together 
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when  installed  on  the  operational  site.  In  that  case,  the  product’s  logbook 
for  the  customer  should  be  used  to  record  such  specific  parameters. 

Example  Work  Products 

1 .  Packaged  product  or  product  components 

2.  Delivery  documentation 
Subpractices 

1 .  Review  the  requirements,  design,  product,  verification  results,  and 
documentation  to  ensure  that  issues  affecting  the  packaging  and 
delivery  of  the  product  are  identified  and  resolved. 

2.  Use  effective  methods  to  package  and  deliver  the  assembled  product. 

I  Examples  of  software  packaging  and  delivery  methods  include  the  following: 

I  •  Magnetic  tape 
I  •  Diskettes 
i  •  Hardcopy  documents 
i  •  Compact  disks 

i  •  Other  electronic  distribution  such  as  the  Internet 

3.  Satisfy  the  applicable  requirements  and  standards  for  packaging  and 
delivering  the  product. 

^ - 

I  Examples  of  requirements  and  standards  Include  ones  for  safety,  the  environment, 

i  security,  transportability,  and  disposal. 


:  Examples  of  requirements  and  standards  for  packaging  and  delivering  software 
i  Include  the  following: 

i  •  Type  of  storage  and  delivery  media 

;  •  Custodians  of  the  master  and  backup  copies 

;  •  Required  documentation 

;  •  Copyrights 

i  •  License  provisions 

I  •  Security  of  the  software 

4.  Prepare  the  operational  site  for  installation  of  the  product. 

Preparing  the  operational  site  can  be  the  responsibility  of  the  customer  or  end  users. 

5.  Deliver  the  product  and  related  documentation  and  confirm  receipt. 

6.  Install  the  product  at  the  operational  site  and  confirm  correct  operation. 

Installing  the  product  can  be  the  responsibility  of  the  customer  or  the  end  users.  In 
some  circumstances,  little  may  need  to  be  done  to  confirm  correct  operation.  In  other 
circumstances,  final  verification  of  the  integrated  product  occurs  at  the  operational  site. 
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PROJECT  MONITORING  AND  CONTROL 

A  Project  Management  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Project  Monitoring  and  Controi  (PMC)  is  to  provide  an 
understanding  of  the  project’s  progress  so  that  appropriate  corrective 
actions  can  be  taken  when  the  project’s  performance  deviates  significantiy 
from  the  pian. 


Introductory  Notes 


A  project’s  documented  pian  is  the  basis  for  monitoring  activities, 
communicating  status,  and  taking  corrective  action.  Progress  is  primariiy 
determined  by  comparing  actuai  work  product  and  task  attributes,  effort, 
cost,  and  scheduie  to  the  pian  at  prescribed  miiestones  or  controi  ieveis  in 
the  project  scheduie  or  WBS.  Appropriate  visibiiity  of  progress  enabies 
timeiy  corrective  action  to  be  taken  when  performance  deviates  significantiy 
from  the  pian.  A  deviation  is  significant  if,  when  ieft  unresoived,  it  preciudes 
the  project  from  meeting  its  objectives. 

The  term  “project  pian”  is  used  throughout  this  process  area  to  refer  to  the 
overaii  pian  for  controiiing  the  project. 

When  actuai  status  deviates  significantiy  from  expected  vaiues,  corrective 
actions  are  taken  as  appropriate.  These  actions  can  require  repianning, 
which  can  inciude  revising  the  originai  pian,  estabiishing  new  agreements, 
or  inciuding  additionai  mitigation  activities  in  the  current  pian. 

Related  Process  Areas 


Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  providing  measurement  results. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  and  maintaining  plans  that  define  project  activities. 
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Specific  Goai  and  Practice  Summary 

SG  1  Monitor  the  Project  Against  the  Pian 

SP  1.1  Monitor  Project  Planning  Parameters 

SP  1 .2  Monitor  Commitments 

SP1.3  Monitor  Project  Risks 

SP  1 .4  Monitor  Data  Management 

SP  1 .5  Monitor  Stakeholder  Involvement 

SP  1 .6  Conduct  Progress  Reviews 

SP  1 .7  Conduct  Milestone  Reviews 

SG  2  Manage  Corrective  Action  to  Closure 
SP  2.1  Analyze  Issues 

SP  2.2  Take  Corrective  Action 

SP  2.3  Manage  Corrective  Actions 

Specific  Practices  by  Goai 


SG  1  Monitor  the  Project  Against  the  Pian 

Actual  project  progress  and  performance  are  monitored  against  the  project 
plan. 


SP  1.1  Monitor  Project  Pianning  Parameters 

Monitor  actual  values  of  project  planning  parameters  against  the 
project  plan. 

Project  planning  parameters  constitute  typical  indicators  of  project  progress 
and  performance  and  include  attributes  of  work  products  and  tasks,  costs, 
effort,  and  schedule.  Attributes  of  the  work  products  and  tasks  include  size, 
complexity,  service  level,  availability,  weight,  form,  fit,  and  function.  The 
frequency  of  monitoring  parameters  should  be  considered. 

Monitoring  typically  involves  measuring  actual  values  of  project  planning 
parameters,  comparing  actual  values  to  estimates  in  the  plan,  and 
identifying  significant  deviations.  Recording  actual  values  of  project 
planning  parameters  includes  recording  associated  contextual  information 
to  help  understand  measures.  An  analysis  of  the  impact  that  significant 
deviations  have  on  determining  the  corrective  actions  to  take  is  handled  in 
specific  goal  2  and  its  specific  practices  in  this  process  area. 

Example  Work  Products 

1 .  Records  of  project  performance 

2.  Records  of  significant  deviations 

3.  Cost  performance  reports 

Subpractices 

1 .  Monitor  progress  against  the  schedule. 
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I  Progress  monitoring  typically  includes  the  following: 

I  •  Periodically  measuring  the  actual  completion  of  activities  and  milestones 

I  •  Comparing  actual  completion  of  activities  and  milestones  against  the  project  plan 
I  schedule 

•  Identifying  significant  deviations  from  the  project  plan  schedule  estimates 


2.  Monitor  the  project’s  costs  and  expended  effort. 

:  Effort  and  cost  monitoring  typically  includes  the  following: 

i  •  Periodically  measuring  the  actual  effort  and  costs  expended  and  staff  assigned 

i  •  Comparing  actual  effort,  costs,  staffing,  and  training  to  the  project  plan  budget  and 
;  estimates 

i  •  Identifying  significant  deviations  from  the  project  plan  budget  and  estimates 

3.  Monitor  the  attributes  of  work  products  and  tasks. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  developing  and  sustaining  a  measurement  capability 
used  to  support  management  information  needs. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  estimates  of  work  product  and  task  attributes. 

i  Monitoring  the  attributes  of  work  products  and  tasks  typically  includes  the  following: 

i  •  Periodically  measuring  the  actual  attributes  of  work  products  and  tasks,  such  as  size, 

;  complexity,  or  service  levels  (and  changes  to  these  attributes) 

i  •  Comparing  the  actual  attributes  of  work  products  and  tasks  (and  changes  to  these 
i  attributes)  to  the  project  plan  estimates 

;  •  Identifying  significant  deviations  from  the  project  plan  estimates 

4.  Monitor  resources  provided  and  used. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  the  project’s  resources. 

I  Examples  of  resources  include  the  following: 

I  •  Physical  facilities 

I  •  Computers,  peripherals,  and  software 

i  •  Networks 

i  •  Security  environment 

i  •  Project  staff 

;  •  Processes 

5.  Monitor  the  knowledge  and  skills  of  project  staff. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  needed  knowledge  and  skills. 
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I  Monitoring  the  knowiedge  and  skiiis  of  project  staff  typicaiiy  inciudes  the  foiiowing: 

I  •  Periodicaiiy  measuring  the  acquisition  of  knowiedge  and  skiiis  by  project  staff 
I  •  Comparing  the  actuai  training  obtained  to  that  documented  in  the  project  pian 
•  Identifying  significant  deviations  from  the  project  plan  estimates 


6.  Document  significant  deviations  in  project  planning  parameters. 

SP1.2  Monitor  Commitments 

Monitor  commitments  against  those  identified  in  the  project  pian. 

Example  Work  Products 

1 .  Records  of  commitment  reviews 

Subpractices 

1 .  Regularly  review  commitments  (both  external  and  internal). 

2.  Identify  commitments  that  have  not  been  satisfied  or  are  at  significant 
risk  of  not  being  satisfied. 

3.  Document  the  results  of  commitment  reviews. 

SP  1 .3  Monitor  Project  Risks 

Monitor  risks  against  those  identified  in  the  project  pian. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  project  risks. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  potential  problems  before  they  occur  so  that  risk  handling 
activities  can  be  planned  and  invoked  as  needed  across  the  life  of  the 
product  or  project  to  mitigate  adverse  impacts  on  achieving  objectives. 

Example  Work  Products 

1 .  Records  of  project  risk  monitoring 

Subpractices 

1 .  Periodically  review  the  documentation  of  risks  in  the  context  of  the 
project’s  current  status  and  circumstances. 

2.  Revise  the  documentation  of  risks  as  additional  information  becomes 
available. 

As  projects  progress  (especially  projects  of  long  duration  or  continuous  operation), 
new  risks  arise.  It  is  important  to  identify  and  analyze  these  new  risks.  For  example, 
software,  equipment,  and  tools  in  use  can  become  obsolete;  or  key  staff  can  gradually 
lose  skills  in  areas  of  particular  long-term  importance  to  the  project  and  organization. 

3.  Communicate  the  risk  status  to  relevant  stakeholders. 

f. - 

I  Examples  of  risk  status  include  the  following: 

:  •  A  change  in  the  probability  that  the  risk  occurs 
i  •  A  change  in  risk  priority 
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SP1.4  Monitor  Data  Management 

Monitor  the  management  of  project  data  against  the  project  pian. 

Refer  to  the  Plan  Data  Management  specific  practice  in  the  Project 
Planning  process  area  for  more  information  about  identifying  types  of  data 
to  be  managed  and  how  to  plan  for  their  management. 

Data  management  activities  should  be  monitored  to  ensure  that  data 
management  requirements  are  being  satisfied.  Depending  on  the  results  of 
monitoring  and  changes  in  project  requirements,  situation,  or  status,  it  may 
be  necessary  to  re-plan  the  project’s  data  management  activities. 

Example  Work  Products 

1 .  Records  of  data  management 

Subpractices 

1 .  Periodically  review  data  management  activities  against  their 
description  in  the  project  plan. 

2.  Identify  and  document  significant  issues  and  their  impacts. 

;  An  example  of  a  significant  issue  is  when  stakeholders  do  not  have  the  access  to 
I  project  data  they  need  to  fulfill  their  roles  as  relevant  stakeholders. 


3.  Document  results  of  data  management  activity  reviews. 

SP  1 .5  Monitor  Stakeholder  Involvement 

Monitor  stakehoider  invoivement  against  the  project  pian. 

Refer  to  the  Plan  Stakeholder  Involvement  specific  practice  in  the  Project 
Planning  process  area  for  more  information  about  identifying  relevant 
stakeholders  and  planning  appropriate  involvement  with  them. 

Stakeholder  involvement  should  be  monitored  to  ensure  that  appropriate 
interactions  occur.  Depending  on  the  results  of  monitoring  and  changes  in 
project  requirements,  situation,  or  status,  it  may  be  necessary  to  re-plan 
stakeholder  involvement. 

i  In  Agile  environments,  the  sustained  involvement  of  customer  and  potential  end  users  in  the 
I  project’s  product  development  activities  can  be  crucial  to  project  success;  thus,  customer 
i  and  end-user  involvement  in  project  activities  should  be  monitored.  (See  Interpreting  CMMI 
I  When  Using  Agile  Approaches”  in  Part  I.) 


Example  Work  Products 

1 .  Records  of  stakeholder  involvement 

Subpractices 

1 .  Periodically  review  the  status  of  stakeholder  involvement. 

2.  Identify  and  document  significant  issues  and  their  impacts. 

3.  Document  the  results  of  stakeholder  involvement  status  reviews. 
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SP  1 .6  Conduct  Progress  Reviews 

Periodically  review  the  project’s  progress,  performance,  and 
issues. 

A  “project’s  progress”  is  the  project’s  status  as  viewed  at  a  particular  time 
when  the  project  activities  performed  so  far  and  their  results  and  impacts 
are  reviewed  with  relevant  stakeholders  (especially  project  representatives 
and  project  management)  to  determine  whether  there  are  significant  issues 
or  performance  shortfalls  to  be  addressed. 

Progress  reviews  are  project  reviews  to  keep  relevant  stakeholders 
informed.  These  project  reviews  can  be  informal  and  may  not  be  specified 
explicitly  in  project  plans. 

Example  Work  Products 

1 .  Documented  project  review  results 

Subpractices 

1 .  Regularly  communicate  status  on  assigned  activities  and  work 
products  to  relevant  stakeholders. 

Managers,  staff,  customers,  end  users,  suppliers,  and  other  relevant  stakeholders  are 
Included  In  reviews  as  appropriate. 

2.  Review  the  results  of  collecting  and  analyzing  measures  for  controlling 
the  project. 

The  measurements  reviewed  can  include  measures  of  customer  satisfaction. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  aligning  measurement  and  analysis  activities  and 
providing  measurement  results. 

3.  Identify  and  document  significant  issues  and  deviations  from  the  plan. 

4.  Document  change  requests  and  problems  identified  in  work  products 
and  processes. 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  tracking  and  controlling  changes. 

5.  Document  the  results  of  reviews. 

6.  Track  change  requests  and  problem  reports  to  closure. 

SP1.7  Conduct  Milestone  Reviews 

Review  the  project’s  accomplishments  and  results  at  selected 
project  milestones. 

Refer  to  the  Establish  the  Budget  and  Schedule  specific  practice  in  the 
Project  Planning  process  area  for  more  information  about  identifying  major 
milestones. 

Milestones  are  pre-planned  events  or  points  in  time  at  which  a  thorough 
review  of  status  is  conducted  to  understand  how  well  stakeholder 
requirements  are  being  met.  (If  the  project  includes  a  developmental 
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milestone,  then  the  review  is  conducted  to  ensure  that  the  assumptions  and 
requirements  associated  with  that  milestone  are  being  met.)  Milestones  can 
be  associated  with  the  overall  project  or  a  particular  service  type  or 
instance.  Milestones  can  thus  be  event  based  or  calendar  based. 

Milestone  reviews  are  planned  during  project  planning  and  are  typically 
formal  reviews. 

Progress  reviews  and  milestone  reviews  need  not  be  held  separately.  A 
single  review  can  address  the  intent  of  both.  For  example,  a  single  pre¬ 
planned  review  can  evaluate  progress,  issues,  and  performance  up  through 
a  planned  time  period  (or  milestone)  against  the  plan’s  expectations. 

Depending  on  the  project,  “project  startup”  and  “project  close-out”  could  be 
phases  covered  by  milestone  reviews. 

Example  Work  Products 

1 .  Documented  milestone  review  results 

Subpractices 

1 .  Conduct  milestone  reviews  with  relevant  stakeholders  at  meaningful 
points  in  the  project’s  schedule,  such  as  the  completion  of  selected 
phases. 

Managers,  staff,  customers,  end  users,  suppliers,  and  other  relevant  stakeholders  are 
included  in  milestone  reviews  as  appropriate. 

2.  Review  commitments,  the  plan,  status,  and  risks  of  the  project. 

3.  Identify  and  document  significant  issues  and  their  impacts. 

4.  Document  results  of  the  review,  action  items,  and  decisions. 

5.  Track  action  items  to  closure. 

SG  2 _ Manage  Corrective  Action  to  Closure _ 

Corrective  actions  are  managed  to  ciosure  when  the  project’s  performance  or 
resuits  deviate  significantiy  from  the  pian. 


SP  2.1  Analyze  Issues 

Coiiect  and  anaiyze  issues  and  determine  corrective  actions  to 
address  them. 

Example  Work  Products 

1 .  List  of  issues  requiring  corrective  actions 
Subpractices 

1 .  Gather  issues  for  analysis. 

Issues  are  collected  from  reviews  and  the  execution  of  other  processes. 
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Examples  of  issues  to  be  gathered  include  the  following: 

•  Issues  discovered  when  performing  technical  reviews,  verification,  and  validation 

•  Significant  deviations  in  project  planning  parameters  from  estimates  in  the  project  plan 

•  Commitments  (either  internal  or  external)  that  have  not  been  satisfied 

•  Significant  changes  in  risk  status 

•  Data  access,  collection,  privacy,  or  security  issues 

•  Stakeholder  representation  or  involvement  issues 

•  Product,  tool,  or  environment  transition  assumptions  (or  other  customer  or  supplier 
commitments)  that  have  not  been  achieved 


2.  Analyze  issues  to  determine  the  need  for  corrective  action. 

Refer  to  the  Establish  the  Budget  and  Schedule  specific  practice  in  the 
Project  Planning  process  area  for  more  information  about  corrective 
action  criteria. 

Corrective  action  is  required  when  the  issue,  if  left  unresolved,  may  prevent  the  project 
from  meeting  its  objectives. 

SP  2.2  Take  Corrective  Action 

Take  corrective  action  on  identified  issues. 

Example  Work  Products 

1 .  Corrective  action  plans 

Subpractices 

1 .  Determine  and  document  the  appropriate  actions  needed  to  address 
identified  issues. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
developing  a  project  plan. 

;  Examples  of  potential  actions  include  the  following: 

;  •  Modifying  the  statement  of  work 
I  •  Modifying  requirements 
I  •  Revising  estimates  and  plans 
I  •  Renegotiating  commitments 
I  •  Adding  resources 
I  •  Changing  processes 
•  Revising  project  risks 

2.  Review  and  get  agreement  with  relevant  stakeholders  on  the  actions  to 
be  taken. 

3.  Negotiate  changes  to  internal  and  external  commitments. 

SP  2.3  Manage  Corrective  Actions 

Manage  corrective  actions  to  ciosure. 
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Example  Work  Products 

1 .  Corrective  action  results 

Subpractices 

1 .  Monitor  corrective  actions  for  their  completion. 

2.  Analyze  results  of  corrective  actions  to  determine  the  effectiveness  of 
the  corrective  actions. 

3.  Determine  and  document  appropriate  actions  to  correct  deviations  from 
planned  results  from  performing  corrective  actions. 

Lessons  learned  as  a  result  of  taking  corrective  action  can  be  inputs  to  planning  and 
risk  management  processes. 
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PROJECT  PLANNING 


A  Project  Management  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Project  Planning  (PP)  is  to  establish  and  maintain  plans  that 
define  project  activities. 


Introductory  Notes 


One  of  the  keys  to  effectively  managing  a  project  is  project  planning.  The 
Project  Planning  process  area  involves  the  following  activities: 

•  Developing  the  project  plan 

•  Interacting  with  relevant  stakeholders  appropriately 

•  Getting  commitment  to  the  plan 

•  Maintaining  the  plan 

Planning  includes  estimating  the  attributes  of  work  products  and  tasks, 
determining  the  resources  needed,  negotiating  commitments,  producing  a 
schedule,  and  identifying  and  analyzing  project  risks.  Iterating  through 
these  activities  may  be  necessary  to  establish  the  project  plan.  The  project 
plan  provides  the  basis  for  performing  and  controlling  project  activities  that 
address  commitments  with  the  project’s  customer.  (See  the  definition  of 
“project”  in  the  glossary.) 

The  project  plan  is  usually  revised  as  the  project  progresses  to  address 
changes  in  requirements  and  commitments,  inaccurate  estimates, 
corrective  actions,  and  process  changes.  Specific  practices  describing  both 
planning  and  replanning  are  contained  in  this  process  area. 

The  term  “project  plan”  is  used  throughout  this  process  area  to  refer  to  the 
overall  plan  for  controlling  the  project.  The  project  plan  can  be  a  stand¬ 
alone  document  or  be  distributed  across  multiple  documents.  In  either  case, 
a  coherent  picture  of  who  does  what  should  be  included.  Likewise, 
monitoring  and  control  can  be  centralized  or  distributed,  as  long  as  at  the 
project  level  a  coherent  picture  of  project  status  can  be  maintained. 
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For  product  lines,  there  are  multiple  sets  of  work  activities  that  would  benefit  from  the 
practices  of  this  process  area.  These  work  activities  include  the  creation  and  maintenance  of 
the  core  assets,  developing  products  to  be  built  using  the  core  assets,  and  orchestrating  the 
overall  product  line  effort  to  support  and  coordinate  the  operations  of  the  inter-related  work 
groups  and  their  activities.  In  Agile  environments,  performing  incremental  development 
involves  planning,  monitoring,  controlling,  and  re-planning  more  frequently  than  in  more 
traditional  development  environments.  While  a  high-level  plan  for  the  overall  project  or  work 
effort  is  typically  established,  teams  will  estimate,  plan,  and  carry  out  the  actual  work  an 
increment  or  iteration  at  a  time.  Teams  typically  do  not  forecast  beyond  what  is  known  about 
the  project  or  iteration,  except  for  anticipating  risks,  major  events,  and  large-scale  influences 
and  constraints.  Estimates  reflect  iteration  and  team  specific  factors  that  influence  the  time, 
effort,  resources,  and  risks  to  accomplish  the  iteration.  Teams  plan,  monitor,  and  adjust 
plans  during  each  iteration  as  often  as  it  takes  (e.g.,  daily).  Commitments  to  plans  are 
demonstrated  when  tasks  are  assigned  and  accepted  during  iteration  planning,  user  stories 
are  elaborated  or  estimated,  and  iterations  are  populated  with  tasks  from  a  maintained 
backlog  of  work.  (See  Interpreting  CMMI  When  Using  Agile  Approaches”  in  Part  I.) 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more  information 
about  eliciting,  analyzing,  and  establishing  customer,  product,  and  product 
component  requirements. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
selecting,  designing,  and  implementing  solutions  to  requirements. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  specifying  measures. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  managing  requirements. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  analyzing  risks  and  mitigating  risks. 
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Specific  Goai  and  Practice  Summary 

SG  1  Establish  Estimates 

SP  1 .1  Estimate  the  Scope  of  the  Project 
SP  1 .2  Establish  Estimates  of  Work  Product  and  Task  Attributes 
SP  1 .3  Define  Project  Lifecycle  Phases 
SP  1 .4  Estimate  Effort  and  Cost 
SG  2  Develop  a  Project  Plan 


SP2.1 

Establish  the  Budget  and  Schedule 

SP2.2 

Identify  Project  Risks 

SP2.3 

Plan  Data  Management 

SP2.4 

Plan  the  Project’s  Resources 

SP2.5 

Plan  Needed  Knowledge  and  Skills 

SP2.6 

Plan  Stakeholder  Involvement 

SP2.7 

Establish  the  Project  Plan 

SG  3  Obtain  Commitment  to  the  Plan 

SP3.1 

Review  Plans  That  Affect  the  Project 

SP3.2 

Reconcile  Work  and  Resource  Levels 

SP3.3 

Obtain  Plan  Commitment 

Specific  Practices  by  Goai 

SG  1 _ Establish  Estimates _ 

Estimates  of  project  planning  parameters  are  established  and  maintained. 

Project  planning  parameters  include  all  information  needed  by  the  project  to 
perform  necessary  planning,  organizing,  staffing,  directing,  coordinating, 
reporting,  and  budgeting. 

Estimates  of  planning  parameters  should  have  a  sound  basis  to  instill 
confidence  that  plans  based  on  these  estimates  are  capable  of  supporting 
project  objectives. 

Factors  to  consider  when  estimating  these  parameters  include  project 
requirements,  including  product  requirements,  requirements  imposed  by  the 
organization,  requirements  imposed  by  the  customer,  and  other 
requirements  that  affect  the  project 

Documentation  of  the  estimating  rationale  and  supporting  data  is  needed 
for  stakeholder  review  and  commitment  to  the  plan  and  for  maintenance  of 
the  plan  as  the  project  progresses. 

SP  1 .1  Estimate  the  Scope  of  the  Project 

Establish  a  top-level  work  breakdown  structure  (WBS)  to  estimate 
the  scope  of  the  project. 

The  WBS  evolves  with  the  project.  A  top-level  WBS  can  serve  to  structure 
initial  estimating.  The  development  of  a  WBS  divides  the  overall  project  into 
an  interconnected  set  of  manageable  components. 

Typically,  the  WBS  is  a  product,  work  product,  or  task  oriented  structure 
that  provides  a  scheme  for  identifying  and  organizing  the  logical  units  of 
work  to  be  managed,  which  are  called  “work  packages.”  The  WBS  provides 
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a  reference  and  organizational  mechanism  for  assigning  effort,  schedule, 
and  responsibility  and  is  used  as  the  underlying  framework  to  plan, 
organize,  and  control  the  work  done  on  the  project. 

Some  projects  use  the  term  “contract  WBS”  to  refer  to  the  portion  of  the 
WBS  placed  under  contract  (possibly  the  entire  WBS).  Not  all  projects  have 
a  contract  WBS  (e.g.,  internally  funded  development). 

Example  Work  Products 

1.  Task  descriptions 

2.  Work  package  descriptions 

3.  WBS 

Subpractices 

1 .  Develop  a  WBS. 

The  WBS  provides  a  scheme  for  organizing  the  project’s  work.  The  WBS  should  permit 
the  identification  of  the  following  items: 

•  Risks  and  their  mitigation  tasks 

•  Tasks  for  deliverables  and  supporting  activities 

•  Tasks  for  skill  and  knowledge  acquisition 

•  Tasks  for  the  development  of  needed  support  plans,  such  as  configuration 
management,  quality  assurance,  and  verification  plans 

•  Tasks  for  the  integration  and  management  of  nondevelopmental  items 

2.  Define  the  work  packages  in  sufficient  detail  so  that  estimates  of 
project  tasks,  responsibilities,  and  schedule  can  be  specified. 

The  top-level  WBS  is  intended  to  help  gauge  the  project  work  effort  for  tasks  and 
organizational  roles  and  responsibilities.  The  amount  of  detail  in  the  WBS  at  this  level 
helps  in  developing  realistic  schedules,  thereby  minimizing  the  need  for  management 
reserve. 

3.  Identify  products  and  product  components  to  be  externally  acquired. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  managing  the  acquisition  of  products  and  services 
from  suppliers. 

4.  Identify  work  products  to  be  reused. 

SP  1 .2  Establish  Estimates  of  Work  Product  and  Task  Attributes 

Establish  and  maintain  estimates  of  work  product  and  task 
attributes. 

Size  is  the  primary  input  to  many  models  used  to  estimate  effort,  cost,  and 
schedule.  Models  can  also  be  based  on  other  attributes  such  as  service 
level,  connectivity,  complexity,  availability,  and  structure. 
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Examples  of  attributes  to  estimate  include  the  following: 

•  Number  and  complexity  of  requirements 

•  Number  and  complexity  of  interfaces 

•  Volume  of  data 

•  Number  of  functions 

•  Function  points 

•  Source  lines  of  code 

•  Number  of  classes  and  objects 

•  Number  of  database  tables 

•  Number  of  fields  in  data  tables 

•  Architecture  elements 

•  Experience  of  project  participants 

•  Amount  of  code  to  be  reused  versus  created 

•  Team  velocity  and  complexity 

•  Number  of  pages 

•  Number  of  inputs  and  outputs 

•  Number  of  technical  risk  items 

•  Number  of  database  tables 

•  Number  of  fields  in  data  tables 

•  Architecture  elements 

•  Experience  of  project  participants 

•  Amount  of  code  to  be  reused  versus  created 

•  Number  of  logic  gates  for  integrated  circuits 

•  Number  of  parts  (e.g.,  printed  circuit  boards,  components,  mechanical  parts) 

•  Physical  constraints  (e.g.,  weight,  volume) 

•  Geographic  dispersal  of  project  members 

•  Proximity  of  customers,  end  users,  and  suppliers 

•  How  agreeable  or  difficult  the  customer  is 

•  Quality  and  "cleanliness”  of  the  existing  code  base 


The  estimates  should  be  consistent  with  project  requirements  to  determine 
the  project’s  effort,  cost,  and  schedule.  A  relative  level  of  difficulty  or 
complexity  should  be  assigned  for  each  size  attribute. 


Example  Work  Products 

1 .  Size  and  complexity  of  tasks  and  work  products 

2.  Estimating  models 

3.  Attribute  estimates 

4.  Technical  approach 
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Subpractices 

1 .  Determine  the  technical  approach  for  the  project. 

The  technical  approach  defines  a  top-level  strategy  for  development  of  the  product.  It 
includes  decisions  on  architectural  features,  such  as  distributed  or  client/server;  state- 
of-the-art  or  established  technologies  to  be  applied,  such  as  robotics,  composite 
materials,  or  artificial  intelligence;  and  the  functionality  and  quality  attributes  expected 
in  the  final  products,  such  as  safety,  security,  and  ergonomics. 

2.  Use  appropriate  methods  to  determine  the  attributes  of  the  work 
products  and  tasks  to  be  used  to  estimate  resource  requirements. 

Methods  for  determining  size  and  complexity  should  be  based  on  validated  models  or 
historical  data. 

The  methods  for  determining  attributes  evolve  as  the  understanding  of  the  relationship 
of  product  characteristics  to  attributes  increases. 

3.  Estimate  the  attributes  of  work  products  and  tasks. 

:  Examples  of  work  products  for  which  size  estimates  are  made  include  the  following: 

i  •  Deliverable  and  nondeliverable  work  products 
i  •  Documents  and  files 

i  •  Operational  and  support  hardware,  firmware,  and  software 


SP  1.3  Define  Project  Lifecycle  Phases 

Define  project  lifecycle  phases  on  which  to  scope  the  planning 
effort. 

The  determination  of  a  project’s  lifecycle  phases  provides  for  planned 
periods  of  evaluation  and  decision  making.  These  periods  are  normally 
defined  to  support  logical  decision  points  at  which  the  appropriateness  of 
continued  reliance  on  the  project  plan  and  strategy  is  determined  and 
significant  commitments  are  made  concerning  resources.  Such  points 
provide  planned  events  at  which  project  course  corrections  and 
determinations  of  future  scope  and  cost  can  be  made. 

Understanding  the  project  lifecycle  is  crucial  in  determining  the  scope  of  the 
planning  effort  and  the  timing  of  initial  planning,  as  well  as  the  timing  and 
criteria  (critical  milestones)  for  replanning. 

The  project  lifecycle  phases  need  to  be  defined  depending  on  the  scope  of 
requirements,  the  estimates  for  project  resources,  and  the  nature  of  the 
project.  Larger  projects  can  contain  multiple  phases,  such  as  concept 
exploration,  development,  production,  operations,  and  disposal.  Within 
these  phases,  subphases  may  be  needed.  A  development  phase  can 
include  subphases  such  as  requirements  analysis,  design,  fabrication, 
integration,  and  verification.  The  determination  of  project  phases  typically 
includes  selection  and  refinement  of  one  or  more  development  models  to 
address  interdependencies  and  appropriate  sequencing  of  the  activities  in 
the  phases. 
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Depending  on  the  strategy  for  development,  there  can  be  intermediate 
phases  for  the  creation  of  prototypes,  increments  of  capability,  or  spiral 
model  cycles.  In  addition,  explicit  phases  for  “project  startup”  and  “project 
close-out”  can  be  included. 

Example  Work  Products 

1 .  Project  lifecycle  phases 

SP  1 .4  Estimate  Effort  and  Cost 

Estimate  the  project’s  effort  and  cost  for  work  products  and  tasks 
based  on  estimation  rationaie. 

Estimates  of  effort  and  cost  are  generally  based  on  results  of  analysis  using 
models  or  historical  data  applied  to  size,  activities,  and  other  planning 
parameters.  Confidence  in  these  estimates  is  based  on  rationale  for  the 
selected  model  and  the  nature  of  the  data.  There  can  be  occasions  when 
available  historical  data  do  not  apply,  such  as  when  efforts  are 
unprecedented  or  when  the  type  of  task  does  not  fit  available  models.  For 
example,  an  effort  can  be  considered  unprecedented  if  the  organization  has 
no  experience  with  such  a  product  or  task. 

Unprecedented  efforts  are  more  risky,  require  more  research  to  develop 
reasonable  bases  of  estimate,  and  require  more  management  reserve.  The 
uniqueness  of  the  project  should  be  documented  when  using  these  models 
to  ensure  a  common  understanding  of  any  assumptions  made  in  the  initial 
planning  phases. 

Example  Work  Products 

1 .  Estimation  rationale 

2.  Project  effort  estimates 

3.  Project  cost  estimates 

Subpractices 

1 .  Collect  models  or  historical  data  to  be  used  to  transform  the  attributes 
of  work  products  and  tasks  into  estimates  of  labor  hours  and  costs. 

Many  parametric  models  have  been  developed  to  help  estimate  cost  and  schedule. 
The  use  of  these  models  as  the  sole  source  of  estimation  Is  not  recommended 
because  these  models  are  based  on  historical  project  data  that  may  or  may  not  be 
pertinent  to  the  project.  Multiple  models  and  methods  can  be  used  to  ensure  a  high 
level  of  confidence  In  the  estimate. 

Historical  data  should  Include  the  cost,  effort,  and  schedule  data  from  previously 
executed  projects  and  appropriate  scaling  data  to  account  for  differing  sizes  and 
complexity. 

2.  Include  supporting  infrastructure  needs  when  estimating  effort  and 
cost. 

The  supporting  infrastructure  includes  resources  needed  from  a  development  and 
sustainment  perspective  for  the  product. 
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Consider  the  infrastructure  resource  needs  in  the  development  environment,  the  test 
environment,  the  production  environment,  the  operational  environment,  or  any 
appropriate  combination  of  these  environments  when  estimating  effort  and  cost. 

Examples  of  infrastructure  resources  include  the  following: 

•  Critical  computer  resources  (e.g.,  memory,  disk  and  network  capacity,  peripherals, 
communication  channels,  the  capacities  of  these  resources) 

•  Engineering  environments  and  tools  (e.g.,  tools  for  prototyping,  testing,  integration, 
assembly,  computer-aided  design  [CAD],  simulation) 

•  Facilities,  machinery,  and  equipment  (e.g.,  test  benches,  recording  devices) 


3.  Estimate  effort  and  cost  using  models,  historical  data,  or  a  combination 
of  both. 

I  Examples  of  effort  and  cost  inputs  used  for  estimating  typically  include  the  following: 

I  •  Estimates  provided  by  an  expert  or  group  of  experts  (e.g.,  Delphi  method.  Extreme 
I  Programming's  Planning  Game) 

I  •  Risks,  including  the  extent  to  which  the  effort  is  unprecedented 
i  •  Critical  competencies  and  roles  needed  to  perform  the  work 
i  •  Travel 
i  •  WBS 

;  •  Selected  project  lifecycle  model  and  processes 
;  •  Lifecycle  cost  estimates 

i  •  Skill  levels  of  managers  and  staff  needed  to  perform  the  work 
i  •  Knowledge,  skill,  and  training  needs 
I  •  Direct  labor  and  overhead 
I  •  Service  agreements  for  call  centers  and  warranty  work 

;  •  Level  of  security  required  for  tasks,  work  products,  hardware,  software,  staff,  and  work 
I  environment 

;  •  Facilities  needed  (e.g.,  office  and  meeting  space  and  workstations) 

I  •  Product  and  product  component  requirements 

I  •  Size  estimates  of  work  products,  tasks,  and  anticipated  changes 

I  •  Cost  of  externally  acquired  products 

I  •  Capability  of  manufacturing  processes 

I  •  Engineering  facilities  needed 

:  •  Capability  of  tools  provided  in  engineering  environment 

I  •  Technical  approach 


SG  2 _ Develop  a  Project  Plan _ 

A  project  plan  is  established  and  maintained  as  the  basis  for  managing  the 
project 

A  project  plan  is  a  formal,  approved  document  used  to  manage  and  control 
the  execution  of  the  project.  It  is  based  on  project  requirements  and 
established  estimates. 
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The  project  plan  should  consider  all  phases  of  the  project  lifecycle.  Project 
planning  should  ensure  that  all  plans  affecting  the  project  are  consistent 
with  the  overall  project  plan. 

SP  2.1  Establish  the  Budget  and  Schedule 

Establish  and  maintain  the  project’s  budget  and  schedule. 

The  project’s  budget  and  schedule  are  based  on  developed  estimates  and 
ensure  that  budget  allocation,  task  complexity,  and  task  dependencies  are 
appropriately  addressed. 

Event  driven,  resource-limited  schedules  have  proven  to  be  effective  in 
dealing  with  project  risk.  Identifying  accomplishments  to  be  demonstrated 
before  initiation  of  an  event  provides  some  flexibility  in  the  timing  of  the 
event,  a  common  understanding  of  what  is  expected,  a  better  vision  of  the 
state  of  the  project,  and  a  more  accurate  status  of  the  project’s  tasks. 

Example  Work  Products 

1 .  Project  schedules 

2.  Schedule  dependencies 

3.  Project  budget 
Subpractices 

1 .  Identify  major  milestones. 

Milestones  are  pre-planned  events  or  points  in  time  at  which  a  thorough  review  of 
status  is  conducted  to  understand  how  well  stakeholder  requirements  are  being  met. 
(If  the  project  includes  a  developmental  milestone,  then  the  review  is  conducted  to 
ensure  that  the  assumptions  and  requirements  associated  with  that  milestone  are 
being  met.)  Milestones  can  be  associated  with  the  overall  project  or  a  particular 
service  type  or  instance.  Milestones  can  thus  be  event  based  or  calendar  based.  If 
calendar  based,  once  agreed,  milestone  dates  are  often  difficult  to  change. 

2.  Identify  schedule  assumptions. 

When  schedules  are  initially  developed,  it  is  common  to  make  assumptions  about  the 
duration  of  certain  activities.  These  assumptions  are  frequently  made  on  items  for 
which  little  if  any  estimation  data  are  available.  Identifying  these  assumptions  provides 
insight  into  the  level  of  confidence  (i.e.,  uncertainties)  in  the  overall  schedule. 

3.  Identify  constraints. 

Factors  that  limit  the  flexibility  of  management  options  should  be  identified  as  early  as 
possible.  The  examination  of  the  attributes  of  work  products  and  tasks  often  bring 
these  issues  to  the  surface.  Such  attributes  can  include  task  duration,  resources, 
inputs,  and  outputs. 

4.  Identify  task  dependencies. 

Frequently,  the  tasks  for  a  project  or  service  can  be  accomplished  in  some  ordered 
sequence  that  minimizes  the  duration.  This  sequencing  involves  the  identification  of 
predecessor  and  successor  tasks  to  determine  optimal  ordering. 
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Examples  of  tools  and  Inputs  that  can  help  determine  optimal  ordering  of  task  activities 
include  the  following: 

•  Critical  Path  Method  (CPM) 

•  Program  Evaluation  and  Review  Technique  (PERT) 

•  Resource  limited  scheduling 

•  Customer  priorities 

•  Marketable  features 

•  End-user  value 


5.  Establish  and  maintain  the  budget  and  schedule. 

f. - 

;  Establishing  and  maintaining  the  project’s  budget  and  schedule  typically  includes  the 
i  following: 

I  •  Defining  the  committed  or  expected  availability  of  resources  and  facilities 
I  •  Determining  the  time  phasing  of  activities 
;  •  Determining  a  breakout  of  subordinate  schedules 

;  •  Defining  dependencies  among  activities  (predecessor  or  successor  relationships) 

I  •  Defining  schedule  activities  and  milestones  to  support  project  monitoring  and  control 

I  •  Identifying  milestones,  releases,  or  increments  for  the  delivery  of  products  to  the 
I  customer 

I  •  Defining  activities  of  appropriate  duration 
I  •  Defining  milestones  of  appropriate  time  separation 

:  •  Defining  a  management  reserve  based  on  the  confidence  level  in  meeting  the  schedule 
I  and  budget 

:  •  Using  appropriate  historical  data  to  verify  the  schedule 
I  •  Defining  incremental  funding  requirements 
I  •  Documenting  project  assumptions  and  rationale 


6.  Establish  corrective  action  criteria. 

Criteria  are  established  for  determining  what  constitutes  a  significant  deviation  from 
the  project  plan.  A  basis  for  gauging  issues  and  problems  is  necessary  to  determine 
when  corrective  action  should  be  taken.  Corrective  actions  can  lead  to  replanning, 
which  may  include  revising  the  original  plan,  establishing  new  agreements,  or  including 
mitigation  activities  in  the  current  plan.  The  project  plan  defines  when  (e.g.,  under  what 
circumstances,  with  what  frequency)  the  criteria  will  be  applied  and  by  whom. 

SP  2.2  Identify  Project  Risks 

Identify  and  analyze  project  risks. 

Refer  to  the  Monitor  Project  Risks  specific  practice  in  the  Project  Monitoring 
and  Controi  process  area  for  more  information  about  risk  monitoring 
activities. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  potentiai  probiems  before  they  occur  so  that  risk  handiing 
activities  can  be  pianned  and  invoked  as  needed  across  the  iife  of  the 
product  or  project  to  mitigate  adverse  impacts  on  achieving  objectives. 
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Risks  are  identified  or  discovered  and  analyzed  to  support  project  planning. 
This  specific  practice  should  be  extended  to  all  plans  that  affect  the  project 
to  ensure  that  appropriate  interfacing  is  taking  place  among  all  relevant 
stakeholders  on  identified  risks. 

f - - 

I  Project  planning  risk  identification  and  analysis  typically  include  the  following: 

I  •  Identifying  risks 

;  •  Analyzing  risks  to  determine  the  impact,  probability  of  occurrence,  and  time  frame  in 
;  which  problems  are  likely  to  occur 

I  •  Prioritizing  risks 


Example  Work  Products 

1 .  Identified  risks 

2.  Risk  impacts  and  probability  of  occurrence 

3.  Risk  priorities 

Subpractices 

1 .  Identify  risks. 

The  identification  of  risks  involves  the  identification  of  potential  issues,  hazards, 
threats,  vulnerabilities,  and  so  on  that  could  negatively  affect  work  efforts  and  plans. 
Risks  should  be  identified  and  described  understandably  before  they  can  be  analyzed 
and  managed  properly.  When  identifying  risks,  it  is  a  good  idea  to  use  a  standard 
method  for  defining  risks.  Risk  identification  and  analysis  tools  can  be  used  to  help 
identify  possible  problems. 

;  Examples  of  risk  identification  and  analysis  tools  include  the  following: 

i  •  Risk  taxonomies 
i  •  Risk  assessments 
I  •  Checklists 
I  •  Structured  interviews 
;  •  Brainstorming 

;  •  Process,  project,  and  product  performance  models 
I  •  Cost  models 
I  •  Network  analysis 
I  •  Quality  factor  analysis 

2.  Document  risks. 

3.  Review  and  obtain  agreement  with  relevant  stakeholders  on  the 
completeness  and  correctness  of  documented  risks. 

4.  Revise  risks  as  appropriate. 
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I  Examples  of  when  identified  risks  may  need  to  be  revised  include  the  following: 

I  •  When  new  risks  are  identified 
I  •  When  risks  become  problems 
I  •  When  risks  are  retired 
•  When  project  circumstances  change  significantly 


SP  2.3  Plan  Data  Management 

Plan  for  the  management  of  project  data. 

Data  are  forms  of  documentation  required  to  support  a  project  in  all  of  its 
areas  (e.g.,  administration,  engineering,  configuration  management, 
finance,  logistics,  quality,  safety,  manufacturing,  procurement).  The  data 
can  take  any  form  (e.g.,  reports,  manuals,  notebooks,  charts,  drawings, 
specifications,  files,  correspondence).  The  data  can  exist  in  any  medium 
(e.g.,  printed  or  drawn  on  various  materials,  photographs,  electronic, 
multimedia). 

Data  can  be  deliverable  (e.g.,  items  identified  by  a  project’s  contract  data 
requirements)  or  data  can  be  nondeliverable  (e.g.,  informal  data,  trade 
studies,  analyses,  internal  meeting  minutes,  internal  design  review 
documentation,  lessons  learned,  action  items).  Distribution  can  take  many 
forms,  including  electronic  transmission. 

Data  requirements  for  the  project  should  be  established  for  both  data  items 
to  be  created  and  their  content  and  form,  based  on  a  common  or  standard 
set  of  data  requirements.  Uniform  content  and  format  requirements  for  data 
items  facilitate  understanding  of  data  content  and  help  with  consistent 
management  of  data  resources. 

The  reason  for  collecting  each  document  should  be  clear.  This  task 
includes  the  analysis  and  verification  of  project  deliverables  and 
nondeliverables,  data  requirements,  and  customer  supplied  data.  Often, 
data  are  collected  with  no  clear  understanding  of  how  they  will  be  used. 
Data  are  costly  and  should  be  collected  only  when  needed. 

Example  Work  Products 

1 .  Data  management  plan 

2.  Master  list  of  managed  data 

3.  Data  content  and  format  description 

4.  Lists  of  data  requirements  for  acquirers  and  suppliers 

5.  Privacy  requirements 

6.  Security  requirements 

7.  Security  procedures 

8.  Mechanisms  for  data  retrieval,  reproduction,  and  distribution 

9.  Schedule  for  the  collection  of  project  data 

1 0.  List  of  project  data  to  be  collected 
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Subpractices 

1 .  Establish  requirements  and  procedures  to  ensure  privacy  and  the 
security  of  data. 

Not  everyone  will  have  the  need  or  clearance  necessary  to  access  project  data. 
Procedures  should  be  established  to  identify  who  has  access  to  which  data  as  well  as 
when  they  have  access  to  which  data. 

2.  Establish  a  mechanism  to  archive  data  and  to  access  archived  data. 

Accessed  information  should  be  in  an  understandable  form  (e.g.,  electronic  or 
computer  output  from  a  database)  or  represented  as  originally  generated. 

3.  Determine  the  project  data  to  be  identified,  collected,  and  distributed. 

4.  Determine  the  requirements  for  providing  access  to  and  distribution  of 
data  to  relevant  stakeholders. 

A  review  of  other  elements  of  the  project  plan  can  help  to  determine  who  requires 
access  to  or  receipt  of  project  data  as  well  as  which  data  are  involved. 

5.  Decide  which  project  data  and  plans  require  version  control  or  other 
levels  of  configuration  control  and  establish  mechanisms  to  ensure 
project  data  are  controlled. 

SP  2.4  Plan  the  Project’s  Resources 

Plan  for  resources  to  perform  the  project. 

Defining  project  resources  (e.g.,  labor,  equipment,  materials,  methods)  and 
quantities  needed  to  perform  project  activities  builds  on  initial  estimates  and 
provides  additional  information  that  can  be  applied  to  expand  the  WBS 
used  to  manage  the  project. 

The  top-level  WBS  developed  earlier  as  an  estimation  mechanism  is 
typically  expanded  by  decomposing  these  top  levels  into  work  packages 
that  represent  single  work  units  that  can  be  separately  assigned, 
performed,  and  tracked.  This  subdivision  is  done  to  distribute  management 
responsibility  and  provide  better  management  control. 

Each  work  package  in  the  WBS  should  be  assigned  a  unique  identifier 
(e.g.,  number)  to  permit  tracking.  A  WBS  can  be  based  on  requirements, 
activities,  work  products,  services,  or  a  combination  of  these  items.  A 
dictionary  that  describes  the  work  for  each  work  package  in  the  WBS 
should  accompany  the  work  breakdown  structure. 

Example  Work  Products 

1 .  Work  packages 

2.  WBS  task  dictionary 

3.  Staffing  requirements  based  on  project  size  and  scope 

4.  Critical  facilities  and  equipment  list 

5.  Process  and  workflow  definitions  and  diagrams 

6.  Project  administration  requirements  list 
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7.  Status  reports 

Subpractices 

1 .  Determine  process  requirements. 

The  processes  used  to  manage  a  project  are  identified,  defined,  and  coordinated  with 
all  relevant  stakeholders  to  ensure  efficient  operations  during  project  execution. 

2.  Determine  communication  requirements. 

These  requirements  address  the  kinds  of  mechanisms  to  be  used  for  communicating 
with  customers,  end  users,  project  staff,  and  other  relevant  stakeholders. 

3.  Determine  staffing  requirements. 

The  staffing  of  a  project  depends  on  the  decomposition  of  project  requirements  into 
tasks,  roles,  and  responsibilities  for  accomplishing  project  requirements  as  laid  out  in 
the  work  packages  of  the  WBS. 

Staffing  requirements  should  consider  the  knowledge  and  skills  required  for  each 
identified  position  as  defined  in  the  Plan  Needed  Knowledge  and  Skills  specific 
practice. 

4.  Determine  facility,  equipment,  and  component  requirements. 

Most  projects  are  unique  in  some  way  and  require  a  set  of  unique  assets  to 
accomplish  project  objectives.  The  determination  and  acquisition  of  these  assets  in  a 
timely  manner  are  crucial  to  project  success. 

It  is  best  to  identify  lead-time  items  early  to  determine  how  they  will  be  addressed. 
Even  when  required  assets  are  not  unique,  compiling  a  list  of  all  facilities,  equipment, 
and  parts  (e.g.,  number  of  computers  for  the  staff  working  on  the  project,  software 
applications,  office  space)  provides  insight  into  aspects  of  the  scope  of  an  effort  that 
are  often  overlooked. 

5.  Determine  other  continuing  resource  requirements. 

Beyond  determining  processes,  reporting  templates,  staffing,  facilities,  and  equipment, 
there  may  be  a  continuing  need  for  other  types  of  resources  to  effectively  carry  out 
project  activities,  including  the  following: 

•  Consumables  (e.g.,  electricity,  office  supplies) 

•  Access  to  intellectual  property 

•  Access  to  transportation  (for  people  and  equipment) 

The  requirements  for  such  resources  are  derived  from  the  requirements  found  in 
(existing  and  future)  agreements  (e.g.,  customer  agreements,  service  agreements, 
supplier  agreements),  the  project’s  strategic  approach,  and  the  need  to  manage  and 
maintain  the  project’s  operations  for  a  period  of  time. 

SP  2.5  Plan  Needed  Knowledge  and  Skills 

Plan  for  knowledge  and  skills  needed  to  perform  the  project. 

Refer  to  the  Organizational  Training  process  area  for  more  information 
about  developing  skills  and  knowledge  of  people  so  they  can  perform  their 
roles  effectively  and  efficiently. 
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Knowledge  delivery  to  projects  involves  training  project  staff  and  acquiring 
knowledge  from  outside  sources. 

Staffing  requirements  are  dependent  on  the  knowledge  and  skills  available 
to  support  the  execution  of  the  project. 

Example  Work  Products 

1 .  Inventory  of  skill  needs 

2.  Staffing  and  new  hire  plans 

3.  Databases  (e.g.,  skills,  training) 

4.  Training  plans 
Subpractices 

1 .  Identify  the  knowledge  and  skills  needed  to  perform  the  project. 

2.  Assess  the  knowledge  and  skills  available. 

3.  Select  mechanisms  for  providing  needed  knowledge  and  skills. 

;  Example  mechanisms  include  the  following: 

i  •  In-house  training  (both  organizational  and  project) 

I  •  External  training 
I  •  Staffing  and  new  hires 
;  •  External  skill  acquisition 


The  choice  of  in-house  training  or  outsourced  training  for  needed  knowledge  and  skills 
is  determined  by  the  availability  of  training  expertise,  the  project’s  schedule,  and 
business  objectives. 

4.  Incorporate  selected  mechanisms  into  the  project  plan. 

SP  2.6  Plan  Stakeholder  Involvement 

Plan  the  involvement  of  identified  stakeholders. 

Stakeholders  are  identified  from  all  phases  of  the  project  lifecycle  by 
identifying  the  people  and  functions  that  should  be  represented  in  the 
project  and  describing  their  relevance  and  the  degree  of  interaction  for 
project  activities.  A  two-dimensional  matrix  with  stakeholders  along  one  axis 
and  project  activities  along  the  other  axis  is  a  convenient  format  for 
accomplishing  this  identification.  Relevance  of  the  stakeholder  to  the 
activity  in  a  particular  project  phase  and  the  amount  of  interaction  expected 
would  be  shown  at  the  intersection  of  the  project  phase  activity  axis  and  the 
stakeholder  axis. 

For  inputs  of  stakeholders  to  be  useful,  careful  selection  of  relevant 
stakeholders  is  necessary.  For  each  major  activity,  identify  stakeholders 
who  are  affected  by  the  activity  and  those  who  have  expertise  that  is 
needed  to  conduct  the  activity.  This  list  of  relevant  stakeholders  will 
probably  change  as  the  project  moves  through  phases  of  the  project 
lifecycle.  It  is  important,  however,  to  ensure  that  relevant  stakeholders  in 
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the  latter  phases  of  the  lifecycle  have  early  input  to  requirements  and 

design  decisions  that  affect  them. 

Examples  of  the  type  of  material  that  should  be  included  in  a  plan  for  stakeholder  interaction 

include  the  following: 

•  List  of  all  relevant  stakeholders 

•  Rationale  for  stakeholder  involvement 

•  Relationships  among  stakeholders 

•  Resources  (e.g.,  training,  materials,  time,  funding)  needed  to  ensure  stakeholder 
interaction 

•  Schedule  for  the  phasing  of  stakeholder  interaction 

•  Roles  and  responsibilities  of  relevant  stakeholders  with  respect  to  the  project,  by  project 
lifecycle  phase 

•  Relative  importance  of  the  stakeholder  to  the  success  of  the  project,  by  project  lifecycle 
phase 


Implementing  this  specific  practice  relies  on  shared  or  exchanged 
information  with  the  previous  Plan  Needed  Knowledge  and  Skills  specific 
practice. 

Example  Work  Products 

1 .  Stakeholder  involvement  plan 

SP  2.7  Establish  the  Project  Plan 

Establish  and  maintain  the  overall  project  plan. 

A  documented  plan  that  addresses  all  relevant  planning  items  is  necessary 
to  achieve  the  mutual  understanding  and  commitment  of  individuals, 
groups,  and  organizations  that  execute  or  support  the  plans. 

The  plan  generated  for  the  project  defines  all  aspects  of  the  effort,  tying 
together  the  following  in  a  logical  manner: 

•  Project  lifecycle  considerations 

•  Project  tasks 

•  Budgets  and  schedules 

•  Milestones 

•  Data  management 

•  Risk  identification 

•  Resource  and  skill  requirements 

•  Stakeholder  identification  and  interaction 

•  Infrastructure  considerations 

Infrastructure  considerations  include  responsibility  and  authority 
relationships  for  project  staff,  management,  and  support  organizations. 

Lifecycle  considerations  can  include  coverage  of  later  phases  of  the  product 
or  service  life  (that  might  be  beyond  the  life  of  the  project),  especially 
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transition  to  another  phase  or  party  (e.g.,  transition  to  manufacturing, 
training,  operations,  a  service  provider). 

For  software,  the  planning  document  is  often  referred  to  as  one  of  the  following: 

•  Software  development  plan 

•  Software  project  plan 

•  Software  plan 


For  hardware,  the  planning  document  is  often  referred  to  as  a  hardware  development  plan. 
Development  activities  in  preparation  for  production  can  be  included  in  the  hardware 
development  plan  or  defined  in  a  separate  production  plan. 


Examples  of  plans  that  have  been  used  in  the  U.S.  Department  of  Defense  community 

include  the  following: 

•  Integrated  Master  Plan— an  event  driven  plan  that  documents  significant 
accomplishments  with  pass/fail  criteria  for  both  business  and  technical  elements  of  the 
project  and  that  ties  each  accomplishment  to  a  key  project  event. 

•  Integrated  Master  Schedule— an  integrated  and  networked  multi-layered  schedule  of 
project  tasks  required  to  complete  the  work  effort  documented  in  a  related  Integrated 
Master  Plan. 

•  Systems  Engineering  Management  Plan— a  plan  that  details  the  integrated  technical 
effort  across  the  project. 

•  Systems  Engineering  Master  Schedule— an  event  based  schedule  that  contains  a 
compilation  of  key  technical  accomplishments,  each  with  measurable  criteria,  requiring 
successful  completion  to  pass  identified  events. 

•  Systems  Engineering  Detailed  Schedule— a  detailed,  time  dependent,  task  oriented 
schedule  that  associates  dates  and  milestones  with  the  Systems  Engineering  Master 
Schedule. 


Example  Work  Products 
1 .  Overall  project  plan 

SG  3  Obtain  Commitment  to  the  Pian 

Commitments  to  the  project  plan  are  established  and  maintained. 

To  be  effective,  plans  require  commitment  by  those  who  are  responsible  for 
implementing  and  supporting  the  plan. 

SP  3.1  Review  Pians  That  Affect  the  Project 

Review  all  plans  that  affect  the  project  to  understand  project 
commitments. 

Plans  developed  in  other  process  areas  typically  contain  information  similar 
to  that  called  for  in  the  overall  project  plan.  These  plans  can  provide 
additional  detailed  guidance  and  should  be  compatible  with  and  support  the 
overall  project  plan  to  indicate  who  has  the  authority,  responsibility, 
accountability,  and  control.  All  plans  that  affect  the  project  should  be 
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reviewed  to  ensure  they  contain  a  common  understanding  of  the  scope, 
objectives,  roles,  and  relationships  that  are  required  for  the  project  to  be 
successful.  Many  of  these  plans  are  described  by  the  Plan  the  Process 
generic  practice. 

Example  Work  Products 

1 .  Record  of  the  reviews  of  plans  that  affect  the  project 

SP  3.2  Reconcile  Work  and  Resource  Levels 

Adjust  the  project  plan  to  reconcile  available  and  estimated 
resources. 

To  establish  a  project  that  is  feasible,  obtain  commitment  from  relevant 
stakeholders  and  reconcile  differences  between  estimates  and  available 
resources.  Reconciliation  is  typically  accomplished  by  modifying  or 
deferring  requirements,  negotiating  more  resources,  finding  ways  to 
increase  productivity,  outsourcing,  adjusting  the  staff  skill  mix,  or  revising  all 
plans  that  affect  the  project  or  its  schedules. 

Example  Work  Products 

1 .  Revised  methods  and  corresponding  estimating  parameters  (e.g., 
better  tools,  the  use  of  off-the-shelf  components) 

2.  Renegotiated  budgets 

3.  Revised  schedules 

4.  Revised  requirements  list 

5.  Renegotiated  stakeholder  agreements 

SP  3.3  Obtain  Plan  Commitment 

Obtain  commitment  from  relevant  stakeholders  responsible  for 
performing  and  supporting  plan  execution. 

Obtaining  commitment  involves  interaction  among  all  relevant  stakeholders, 
both  internal  and  external  to  the  project.  The  individual  or  group  making  a 
commitment  should  have  confidence  that  the  work  can  be  performed  within 
cost,  schedule,  and  performance  constraints.  Often,  a  provisional 
commitment  is  adequate  to  allow  the  effort  to  begin  and  to  permit  research 
to  be  performed  to  increase  confidence  to  the  appropriate  level  needed  to 
obtain  a  full  commitment. 

Example  Work  Products 

1 .  Documented  requests  for  commitments 

2.  Documented  commitments 

Subpractices 

1 .  Identify  needed  support  and  negotiate  commitments  with  relevant 
stakeholders. 

The  WBS  can  be  used  as  a  checklist  for  ensuring  that  commitments  are  obtained  for 
all  tasks. 
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The  plan  for  stakeholder  Interaction  should  Identify  all  parties  from  whom  commitment 
should  be  obtained. 

2.  Document  all  organizational  commitments,  both  full  and  provisional, 
ensuring  the  appropriate  level  of  signatories. 

Commitments  should  be  documented  to  ensure  a  consistent  mutual  understanding 
and  for  project  tracking  and  maintenance.  Provisional  commitments  should  be 
accompanied  by  a  description  of  risks  associated  with  the  relationship. 

3.  Review  internal  commitments  with  senior  management  as  appropriate. 

4.  Review  external  commitments  with  senior  management  as  appropriate. 

Management  can  have  the  necessary  insight  and  authority  to  reduce  risks  associated 
with  external  commitments. 

5.  Identify  commitments  regarding  interfaces  between  project  elements 
and  other  projects  and  organizational  units  so  that  these  commitments 
can  be  monitored. 

Well-defined  interface  specifications  form  the  basis  for  commitments. 
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PROCESS  AND  PRODUCT  QUALITY  ASSURANCE 

A  Support  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Process  and  Product  Quality  Assurance  (PPQA)  is  to 
provide  staff  and  management  with  objective  insight  into  processes  and 
associated  work  products. 


Introductory  Notes 


The  Process  and  Product  Quality  Assurance  process  area  involves  the 
following  activities: 

•  Qbjectively  evaluating  performed  processes  and  work  products  against 
applicable  process  descriptions,  standards,  and  procedures 

•  Identifying  and  documenting  noncompliance  issues 

•  Providing  feedback  to  project  staff  and  managers  on  the  results  of 
quality  assurance  activities 

•  Ensuring  that  noncompliance  issues  are  addressed 

The  Process  and  Product  Quality  Assurance  process  area  supports  the 
delivery  of  high-quality  products  by  providing  project  staff  and  managers  at 
all  levels  with  appropriate  visibility  into,  and  feedback  on,  processes  and 
associated  work  products  throughout  the  life  of  the  project. 

The  practices  in  the  Process  and  Product  Quality  Assurance  process  area 
ensure  that  planned  processes  are  implemented,  while  the  practices  in  the 
Verification  process  area  ensure  that  specified  requirements  are  satisfied. 
These  two  process  areas  can  on  occasion  address  the  same  work  product 
but  from  different  perspectives.  Projects  should  take  advantage  of  the 
overlap  to  minimize  duplication  of  effort  while  taking  care  to  maintain 
separate  perspectives. 

Qbjectivity  in  process  and  product  quality  assurance  evaluations  is  critical 
to  the  success  of  the  project.  (See  the  definition  of  “objectively  evaluate”  in 
the  glossary.)  Qbjectivity  is  achieved  by  both  independence  and  the  use  of 
criteria.  A  combination  of  methods  providing  evaluations  against  criteria  by 
those  who  do  not  produce  the  work  product  is  often  used.  Less  formal 
methods  can  be  used  to  provide  broad  day-to-day  coverage.  More  formal 
methods  can  be  used  periodically  to  assure  objectivity. 
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Examples  of  ways  to  perform  objective  evaluations  include  the  following: 

•  Formal  audits  by  organizationally  separate  quality  assurance  organizations 

•  Peer  reviews,  which  can  be  performed  at  various  levels  of  formality 

•  In-depth  review  of  work  at  the  place  it  is  performed  (i.e.,  desk  audits) 

•  Distributed  review  and  comment  of  work  products 

•  Process  checks  built  into  the  processes  such  as  a  fail-safe  for  processes  when  they  are 
done  incorrectly  (e.g.,  Poka-Yoke) 


Traditionally,  a  quality  assurance  group  that  is  independent  of  the  project 
provides  objectivity.  However,  another  approach  may  be  appropriate  in 
some  organizations  to  implement  the  process  and  product  quality 

assurance  role  without  that  kind  of  independence. 

- - - - - - - 

I  For  example,  in  an  organization  with  an  open,  quality  oriented  culture,  the  process  and 
;  product  quality  assurance  role  can  be  performed,  partially  or  completely,  by  peers  and  the 
I  quality  assurance  function  can  be  embedded  in  the  process.  For  small  organizations,  this 
i  embedded  approach  might  be  the  most  feasible  approach. 


If  quality  assurance  is  embedded  in  the  process,  several  issues  should  be 
addressed  to  ensure  objectivity.  Everyone  performing  quality  assurance 
activities  should  be  trained  in  quality  assurance.  Those  who  perform  quality 
assurance  activities  for  a  work  product  should  be  separate  from  those  who 
are  directly  involved  in  developing  or  maintaining  the  work  product.  An 
independent  reporting  channel  to  the  appropriate  level  of  organizational 
management  should  be  available  so  that  noncompliance  issues  can  be 
escalated  as  necessary. 

For  example,  when  implementing  peer  reviews  as  an  objective  evaluation  method,  the 
following  issues  should  be  addressed: 

•  Members  are  trained  and  roles  are  assigned  for  people  attending  the  peer  reviews. 

•  A  member  of  the  peer  review  who  did  not  produce  this  work  product  is  assigned  to 
perform  the  quality  assurance  role. 

•  Checklists  based  on  process  descriptions,  standards,  and  procedures  are  available  to 
support  the  quality  assurance  activity. 

•  Noncompliance  issues  are  recorded  as  part  of  the  peer  review  report  and  are  tracked 
and  escalated  outside  the  project  when  necessary. 


Quality  assurance  should  begin  in  the  early  phases  of  a  project  to  establish 
plans,  processes,  standards,  and  procedures  that  will  add  value  to  the 
project  and  satisfy  the  requirements  of  the  project  and  organizational 
policies.  Those  who  perform  quality  assurance  activities  participate  in 
establishing  plans,  processes,  standards,  and  procedures  to  ensure  that 
they  fit  project  needs  and  that  they  will  be  usable  for  performing  quality 
assurance  evaluations.  In  addition,  processes  and  associated  work 
products  to  be  evaluated  during  the  project  are  designated.  This 
designation  can  be  based  on  sampling  or  on  objective  criteria  that  are 
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consistent  with  organizational  policies,  project  requirements,  and  project 
needs. 

When  noncompliance  issues  are  identified,  they  are  first  addressed  in  the 
project  and  resolved  there  if  possible.  Noncompliance  issues  that  cannot  be 
resolved  in  the  project  are  escalated  to  an  appropriate  level  of  management 
for  resolution. 

This  process  area  applies  to  evaluations  of  project  activities  and  work 
products,  and  to  organizational  (e.g.,  process  group,  organizational  training) 
activities  and  work  products.  For  organizational  activities  and  work 
products,  the  term  “project”  should  be  appropriately  interpreted. 

In  Agile  environments,  teams  tend  to  focus  on  immediate  needs  of  the  iteration  rather  than 
on  longer  term  and  broader  organizational  needs.  To  ensure  that  objective  evaluations  are 
perceived  to  have  value  and  are  efficient,  discuss  the  following  early:  (1)  how  objective 
evaluations  are  to  be  done,  (2)  which  processes  and  work  products  will  be  evaluated,  (3) 
how  results  of  evaluations  will  be  integrated  into  the  team’s  rhythms  (e.g.,  as  part  of  daily 
meetings,  checklists,  peer  reviews,  tools,  continuous  integration,  retrospectives).  (See 
“Interpreting  CMMI  When  Using  Agile  Approaches”  in  Part  I.) 


Related  Process  Areas 

Refer  to  the  Verification  process  area  for  more  information  about  ensuring 
that  seiected  work  products  meet  their  specified  requirements. 

Specific  Goal  and  Practice  Summary 

SG  1  Objectively  Evaluate  Processes  and  Work  Products 
SP  1.1  Objectively  Evaluate  Processes 
SP  1 .2  Objectively  Evaluate  Work  Products 
SG  2  Provide  Objective  Insight 

SP  2.1  Communicate  and  Resolve  Noncompliance  Issues 

SP  2.2  Establish  Records 

Specific  Practices  by  Goal 


SG  1  Objectively  Evaluate  Processes  and  Work  Products 

Adherence  of  the  performed  process  and  associated  work  products  to 
applicable  process  descriptions,  standards,  and  procedures  is  objectively 
evaluated. 


SP  1 .1  Objectively  Evaluate  Processes 

Objectively  evaluate  selected  performed  processes  against 
applicable  process  descriptions,  standards,  and  procedures. 

Objectivity  in  quality  assurance  evaluations  is  critical  to  the  success  of  the 
project.  A  description  of  the  quality  assurance  reporting  chain  and  how  it 
ensures  objectivity  should  be  defined. 

Example  Work  Products 

1 .  Evaluation  reports 
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2.  Noncompliance  reports 

3.  Corrective  actions 

Subpractices 

1 .  Promote  an  environment  (created  as  part  of  project  management)  that 
encourages  staff  participation  in  identifying  and  reporting  quality 
issues. 

2.  Establish  and  maintain  clearly  stated  criteria  for  evaluations. 

The  intent  of  this  subpractice  is  to  provide  criteria,  based  on  business  needs,  such  as 
the  following: 

•  What  will  be  evaluated 

•  When  or  how  often  a  process  will  be  evaluated 

•  How  the  evaluation  will  be  conducted 

•  Who  must  be  involved  in  the  evaluation 

3.  Use  the  stated  criteria  to  evaluate  selected  performed  processes  for 
adherence  to  process  descriptions,  standards,  and  procedures. 

4.  Identify  each  noncompliance  found  during  the  evaluation. 

5.  Identify  lessons  learned  that  could  improve  processes. 

SP  1 .2  Objectively  Evaluate  Work  Products 

Objectively  evaluate  selected  work  products  against  applicable 
process  descriptions,  standards,  and  procedures. 


Example  Work  Products 

1 .  Evaluation  reports 

2.  Noncompliance  reports 

3.  Corrective  actions 
Subpractices 

1 .  Select  work  products  to  be  evaluated  based  on  documented  sampling 
criteria  if  sampling  is  used. 

Work  products  can  include  services  produced  by  a  process  whether  the  recipient  of 
the  service  is  internal  or  external  to  the  project  or  organization. 

2.  Establish  and  maintain  clearly  stated  criteria  for  the  evaluation  of 
selected  work  products. 

The  intent  of  this  subpractice  is  to  provide  criteria,  based  on  business  needs,  such  as 
the  following: 

•  What  will  be  evaluated  during  the  evaluation  of  a  work  product 

•  When  or  how  often  a  work  product  will  be  evaluated 

•  How  the  evaluation  will  be  conducted 

•  Who  must  be  involved  in  the  evaluation 

3.  Use  the  stated  criteria  during  evaluations  of  selected  work  products. 
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4.  Evaluate  selected  work  products  at  selected  times. 

I  Examples  of  when  work  products  can  be  evaluated  against  process  descriptions, 
i  standards,  or  procedures  include  the  following: 

;  •  Before  delivery  to  the  customer 
;  •  During  delivery  to  the  customer 
I  •  Incrementally,  when  it  is  appropriate 
I  •  During  unit  testing 
I  •  During  integration 
I  •  When  demonstrating  an  increment 

5.  Identify  each  case  of  noncompliance  found  during  evaluations. 

6.  Identify  lessons  learned  that  could  improve  processes. 

SG  2 _ Provide  Objective  Insight _ 

Noncompliance  issues  are  objectively  tracked  and  communicated,  and 
resolution  is  ensured. 


SP  2.1  Communicate  and  Resolve  Noncompliance  Issues 

Communicate  quality  issues  and  ensure  the  resolution  of 
noncompliance  issues  with  the  staff  and  managers. 

Noncompliance  issues  are  problems  identified  in  evaluations  that  reflect  a 
lack  of  adherence  to  applicable  standards,  process  descriptions,  or 
procedures.  The  status  of  noncompliance  issues  provides  an  indication  of 
quality  trends.  Quality  issues  include  noncompliance  issues  and  trend 
analysis  results. 

When  noncompliance  issues  cannot  be  resolved  in  the  project,  use 
established  escalation  mechanisms  to  ensure  that  the  appropriate  level  of 
management  can  resolve  the  issue.  Track  noncompliance  issues  to 
resolution. 

Example  Work  Products 

1 .  Corrective  action  reports 

2.  Evaluation  reports 

3.  Quality  trends 
Subpractices 

1 .  Resolve  each  noncompliance  with  the  appropriate  members  of  the  staff 
if  possible. 

2.  Document  noncompliance  issues  when  they  cannot  be  resolved  in  the 
project. 
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Examples  of  ways  to  resolve  noncompllance  In  the  project  Include  the  following: 

•  Fixing  the  noncompllance 

•  Changing  the  process  descriptions,  standards,  or  procedures  that  were  violated 

•  Obtaining  a  waiver  to  cover  the  noncompllance 


3.  Escalate  noncompliance  issues  that  cannot  be  resolved  in  the  project 
to  the  appropriate  level  of  management  designated  to  receive  and  act 
on  noncompliance  issues. 

4.  Analyze  noncompliance  issues  to  see  if  there  are  quality  trends  that 
can  be  identified  and  addressed. 

5.  Ensure  that  relevant  stakeholders  are  aware  of  results  of  evaluations 
and  quality  trends  in  a  timely  manner. 

6.  Periodically  review  open  noncompliance  issues  and  trends  with  the 
manager  designated  to  receive  and  act  on  noncompliance  issues. 

7.  Track  noncompliance  issues  to  resolution. 

SP  2.2  Establish  Records 

Establish  and  maintain  records  of  quality  assurance  activities. 


Example  Work  Products 

1 .  Evaluation  logs 

2.  Quality  assurance  reports 

3.  Status  reports  of  corrective  actions 

4.  Reports  of  quality  trends 
Subpractices 

1 .  Record  process  and  product  quality  assurance  activities  in  sufficient 
detail  so  that  status  and  results  are  known. 

2.  Revise  the  status  and  history  of  quality  assurance  activities  as 
necessary. 
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QUANTITATIVE  PROJECT  MANAGEMENT 

A  Project  Management  Process  Area  at  Maturity  Level  4 


Purpose 


The  purpose  of  Quantitative  Project  Management  (QPM)  is  to  quantitatively 
manage  the  project  to  achieve  the  project’s  established  quality  and  process 
performance  objectives. 


Introductory  Notes 


The  Quantitative  Project  Management  process  area  involves  the  following 
activities: 

•  Establishing  and  maintaining  the  project’s  quality  and  process 
performance  objectives 

•  Composing  a  defined  process  for  the  project  to  help  to  achieve  the 
project’s  quality  and  process  performance  objectives 

•  Selecting  subprocesses  and  attributes  critical  to  understanding 
performance  and  that  help  to  achieve  the  project’s  quality  and  process 
performance  objectives 

•  Selecting  measures  and  analytic  techniques  to  be  used  in  quantitative 
management 

•  Monitoring  the  performance  of  selected  subprocesses  using  statistical 
and  other  quantitative  techniques 

•  Managing  the  project  using  statistical  and  other  quantitative  techniques 
to  determine  whether  or  not  the  project’s  objectives  for  quality  and 
process  performance  are  being  satisfied 

•  Performing  root  cause  analysis  of  selected  issues  to  address 
deficiencies  in  achieving  the  project’s  quality  and  process  performance 
objectives 

Qrganizational  process  assets  used  to  achieve  high  maturity,  including 
quality  and  process  performance  objectives,  selected  processes,  measures, 
baselines,  and  models,  are  established  using  organizational  process 
performance  processes  and  used  in  quantitative  project  management 
processes.  The  project  can  use  organizational  process  performance 
processes  to  define  additional  objectives,  measures,  baselines,  and  models 
as  needed  to  effectively  analyze  and  manage  performance.  The  measures, 
measurements,  and  other  data  resulting  from  quantitative  project 
management  processes  are  incorporated  into  the  organizational  process 
assets.  In  this  way,  the  organization  and  its  projects  derive  benefit  from 
assets  improved  through  use. 

The  project’s  defined  process  is  a  set  of  interrelated  subprocesses  that  form 
an  integrated  and  coherent  process  for  the  project.  The  Integrated  Project 
Management  practices  describe  establishing  the  project’s  defined  process 
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by  selecting  and  tailoring  processes  from  the  organization’s  set  of  standard 
processes.  (See  the  definition  of  “defined  process”  in  the  glossary.) 

Quantitative  Project  Management  practices,  unlike  Integrated  Project 
Management  practices,  help  you  to  develop  a  quantitative  understanding  of 
the  expected  performance  of  processes  or  subprocesses.  This 
understanding  is  used  as  a  basis  for  establishing  the  project’s  defined 
process  by  evaluating  alternative  processes  or  subprocesses  for  the  project 
and  selecting  the  ones  that  will  best  achieve  the  quality  and  process 
performance  objectives. 

Establishing  effective  relationships  with  suppliers  is  also  important  to  the 
successful  implementation  of  this  process  area.  Establishing  effective 
relationships  can  involve  establishing  quality  and  process  performance 
objectives  for  suppliers,  determining  the  measures  and  analytic  techniques 
to  be  used  to  gain  insight  into  supplier  progress  and  performance,  and 
monitoring  progress  toward  achieving  those  objectives. 

An  essential  element  of  quantitative  management  is  having  confidence  in 
predictions  (i.e.,  the  ability  to  accurately  predict  the  extent  to  which  the 
project  can  fulfill  its  quality  and  process  performance  objectives). 
Subprocesses  to  be  managed  through  the  use  of  statistical  and  other 
quantitative  techniques  are  chosen  based  on  the  needs  for  predictable 
process  performance. 

Another  essential  element  of  quantitative  management  is  understanding  the 
nature  and  extent  of  the  variation  experienced  in  process  performance  and 
recognizing  when  the  project’s  actual  performance  may  not  be  adequate  to 
achieve  the  project’s  quality  and  process  performance  objectives. 

Thus,  quantitative  management  includes  statistical  thinking  and  the  correct 
use  of  a  variety  of  statistical  techniques.  (See  the  definition  of  “quantitative 
management”  in  the  glossary.) 

Statistical  and  other  quantitative  techniques  are  used  to  develop  an 
understanding  of  the  actual  performance  or  to  predict  the  performance  of 
processes.  Such  techniques  can  be  applied  at  multiple  levels,  from  a  focus 
on  individual  subprocesses  to  analyses  that  span  lifecycle  phases,  projects, 
and  support  functions.  Non-statistical  techniques  provide  a  less  rigorous  but 
still  useful  set  of  approaches  that  together  with  statistical  techniques  help 
the  project  to  understand  whether  or  not  quality  and  process  performance 
objectives  are  being  satisfied  and  to  identify  any  needed  corrective  actions. 

This  process  area  applies  to  managing  a  project.  Applying  these  concepts 
to  managing  other  groups  and  functions  can  help  to  link  different  aspects  of 
performance  in  the  organization  to  provide  a  basis  for  balancing  and 
reconciling  competing  priorities  to  address  a  broader  set  of  business 
objectives. 
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Examples  of  other  groups  and  functions  that  could  benefit  from  using  this  process  area 
include  the  following: 

•  Quality  assurance  or  quality  control  functions 

•  Process  definition  and  improvement 

•  Internal  research  and  development  functions 

•  Risk  identification  and  management  functions 

•  Technology  scouting  functions 

•  Market  research 

•  Customer  satisfaction  assessment 

•  Problem  tracking  and  reporting 


Related  Process  Areas 


Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  identifying  causes  of  selected  outcomes  and  taking  action 
to  improve  process  performance. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  aligning  measurement  and  analysis  activities  and  providing 
measurement  results. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets. 

Refer  to  the  Organizational  Performance  Management  process  area  for 
more  information  about  proactively  managing  the  organization’s 
performance  to  meet  its  business  objectives. 

Refer  to  the  Organizational  Process  Performance  process  area  for  more 
information  about  establishing  and  maintaining  a  quantitative  understanding 
of  the  performance  of  selected  processes  in  the  organization’s  set  of 
standard  processes  in  support  of  achieving  quality  and  process 
performance  objectives,  and  providing  process  performance  data, 
baselines,  and  models  to  quantitatively  manage  the  organization’s  projects. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  providing  an  understanding  of  the  project’s  progress  so 
that  appropriate  corrective  actions  can  be  taken  when  the  project’s 
performance  deviates  significantly  from  the  plan. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  managing  the  acquisition  of  products  and  services  from 
suppliers. 
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Specific  Goai  and  Practice  Summary 

SG  1  Prepare  for  Quantitative  Management 

SP  1 .1  Estabiish  the  Project’s  Objectives 
SP  1 .2  Compose  the  Defined  Process 
SP  1 .3  Seiect  Subprocesses  and  Attributes 
SP  1 .4  Seiect  Measures  and  Anaiytic  Techniques 

SG  2  Quantitatively  Manage  the  Project 

SP  2.1  Monitor  the  Performance  of  Selected  Subprocesses 
SP  2.2  Manage  Project  Performance 

SP  2.3  Perform  Root  Cause  Analysis 

Specific  Practices  by  Goai 


SG  1 _ Prepare  for  Quantitative  Management _ 

Preparation  for  quantitative  management  is  conducted. 

Preparation  activities  include  establishing  quantitative  objectives  for  the 
project,  composing  a  defined  process  for  the  project  that  can  help  to 
achieve  those  objectives,  selecting  subprocesses  and  attributes  critical  to 
understanding  performance  and  achieving  the  objectives,  and  selecting 
measures  and  analytic  techniques  that  support  quantitative  management. 

These  activities  may  need  to  be  repeated  when  needs  and  priorities 
change,  when  there  is  an  improved  understanding  of  process  performance, 
or  as  part  of  risk  mitigation  or  corrective  action. 

SP  1.1  Establish  the  Project’s  Objectives 

Estabiish  and  maintain  the  project’s  quaiity  and  process 
performance  objectives. 

When  establishing  the  project’s  quality  and  process  performance 
objectives,  think  about  the  processes  that  will  be  included  in  the  project’s 
defined  process  and  what  the  historical  data  indicate  regarding  their 
process  performance.  These  considerations,  along  with  others  such  as 
technical  capability,  will  help  in  establishing  realistic  objectives  for  the 
project. 

The  project’s  objectives  for  quality  and  process  performance  are 
established  and  negotiated  at  an  appropriate  level  of  detail  (e.g.,  for 
individual  product  components,  subprocesses,  project  teams)  to  permit  an 
overall  evaluation  of  the  objectives  and  risks  at  the  project  level.  As  the 
project  progresses,  project  objectives  can  be  updated  as  the  project’s 
actual  performance  becomes  known  and  more  predictable,  and  to  reflect 
changing  needs  and  priorities  of  relevant  stakeholders. 

Example  Work  Products 

1 .  The  project’s  quality  and  process  performance  objectives 

2.  Assessment  of  the  risk  of  not  achieving  the  project’s  objectives 
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Subpractices 

1 .  Review  the  organization's  objectives  for  quality  and  process 
performance. 

This  review  ensures  that  project  members  understand  the  broader  business  context  in 
which  the  project  operates.  The  project’s  objectives  for  quality  and  process 
performance  are  developed  In  the  context  of  these  overarching  organizational 
objectives. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  establishing  quality  and  process  performance 
objectives. 

2.  Identify  the  quality  and  process  performance  needs  and  priorities  of  the 
customer,  suppliers,  end  users,  and  other  relevant  stakeholders. 

Typically,  the  identification  of  relevant  stakeholders’  needs  will  begin  early  (e.g.,  during 
development  of  the  statement  of  work).  Needs  are  further  elicited,  analyzed,  refined, 
prioritized,  and  balanced  during  requirements  development. 

i  Examples  of  quality  and  process  performance  attributes  for  which  needs  and  priorities 
I  might  be  identified  include  the  following: 

I  •  Duration 
I  •  Predictability 
I  •  Reliability 
:  •  Maintainability 
i  •  Usability 
i  •  Timeliness 
i  •  Functionality 
i  •  Accuracy 


3.  Define  and  document  measurable  quality  and  process  performance 
objectives  for  the  project. 

Defining  and  documenting  objectives  for  the  project  involve  the  following: 

•  Incorporating  appropriate  organizational  quality  and  process  performance  objectives 

•  Writing  objectives  that  reflect  the  quality  and  process  performance  needs  and  priorities 
of  the  customer,  end  users,  and  other  relevant  stakeholders 

•  Determining  how  each  objective  will  be  achieved 

•  Reviewing  the  objectives  to  ensure  they  are  sufficiently  specific,  measurable, 
attainable,  relevant,  and  time-bound 

;  Examples  of  measurable  quality  attributes  include  the  following: 

i  •  Mean  time  between  failures 
i  •  Number  and  severity  of  defects  in  the  released  product 
I  •  Critical  resource  utilization 

I  •  Number  and  severity  of  customer  complaints  concerning  the  provided  service 
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Examples  of  measurable  process  performance  attributes  Include  the  following: 

•  Cycle  time 

•  Percentage  of  rework  time 

•  Percentage  of  defects  removed  by  product  verification  activities  (perhaps  by  type  of 
verification,  such  as  peer  reviews  and  testing) 

•  Defect  escape  rates 

•  Number  and  severity  of  defects  found  (or  incidents  reported)  in  first  year  following 
product  delivery  (or  start  of  service) 


Examples  of  project  quality  and  process  performance  objectives  include: 

•  Maintain  change  request  backlog  size  below  a  target  value. 

•  Improve  velocity  in  an  Agile  environment  to  a  target  value  by  a  target  date. 

•  Reduce  idle  time  by  x%  by  a  target  date. 

•  Maintain  schedule  slippage  below  a  specified  percent. 

•  Reduce  the  total  lifecycle  cost  by  a  specified  percent  by  a  target  date. 

•  Reduce  defects  in  products  delivered  to  the  customer  by  10%  without  affecting  cost. 


4.  Derive  interim  objectives  to  monitor  progress  toward  achieving  the 
project’s  objectives. 

Interim  objectives  can  be  established  for  attributes  of  selected  lifecycle  phases, 
milestones,  work  products,  and  subprocesses. 

Since  process  performance  models  characterize  relationships  among  product  and 
process  attributes,  these  models  can  be  used  to  help  derive  interim  objectives  that 
guide  the  project  toward  achieving  its  objectives. 

5.  Determine  the  risk  of  not  achieving  the  project’s  quality  and  process 
performance  objectives. 

The  risk  is  a  function  of  the  established  objectives,  the  product  architecture,  the 
project’s  defined  process,  availability  of  needed  knowledge  and  skills,  etc.  Process 
performance  baselines  and  models  can  be  used  to  evaluate  the  likelihood  of  achieving 
a  set  of  objectives  and  provide  guidance  in  negotiating  objectives  and  commitments. 
The  assessment  of  risk  can  involve  various  project  stakeholders  and  can  be  conducted 
as  part  of  the  conflict  resolution  described  in  the  next  subpractice. 

6.  Resolve  conflicts  among  the  project’s  quality  and  process  performance 
objectives  (e.g.,  if  one  objective  cannot  be  achieved  without 
compromising  another). 

Process  performance  models  can  help  to  identify  conflicts  and  help  to  ensure  that  the 
resolution  of  conflicts  does  not  introduce  new  conflicts  or  risks. 

Resolving  conflicts  involves  the  following  activities: 

•  Setting  relative  priorities  for  objectives 

•  Considering  alternative  objectives  in  light  of  long-term  business  strategies  as  well  as 
short-term  needs 
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•  Involving  the  customer,  end  users,  senior  management,  project  management,  and 
other  relevant  stakeholders  in  tradeoff  decisions 

•  Revising  objectives  as  necessary  to  reflect  results  of  conflict  resolution 

7.  Establish  traceability  to  the  project’s  quality  and  process  performance 
objectives  from  their  sources. 

;  Examples  of  sources  of  objectives  include  the  following: 

I  •  Requirements 

I  •  The  organization's  quality  and  process  performance  objectives 
I  •  The  customer's  quality  and  process  performance  objectives 
I  •  Business  objectives 

I  •  Discussions  with  customers  and  potential  customers 
I  •  Market  surveys 
I  •  Product  Architecture 


An  example  of  a  method  to  identify  and  trace  these  needs  and  priorities  is  Quality 
Function  Deployment  (QFD). 


8.  Define  and  negotiate  quality  and  process  performance  objectives  for 
suppliers. 

9.  Revise  the  project’s  quality  and  process  performance  objectives  as 
necessary. 

SP  1.2  Compose  the  Defined  Process 

Using  statistical  and  other  quantitative  techniques,  compose  a 
defined  process  that  enables  the  project  to  achieve  its  quality  and 
process  performance  objectives. 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets. 

Refer  to  the  Organizational  Process  Performance  process  area  for  more 
information  about  establishing  performance  baselines  and  models. 

Composing  the  project’s  defined  process  goes  beyond  the  process 
selection  and  tailoring  described  in  the  Integrated  Project  Management 
process  area.  It  involves  identifying  alternatives  to  one  or  more  processes 
or  subprocesses,  performing  quantitative  analysis  of  performance  and 
selecting  the  alternatives  that  are  best  able  to  help  the  project  to  achieve  its 
quality  and  process  performance  objectives. 

Example  Work  Products 

1 .  Criteria  used  to  evaluate  alternatives  for  the  project 

2.  Alternative  subprocesses 

3.  Subprocesses  to  be  included  in  the  project’s  defined  process 
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4.  Assessment  of  risk  of  not  achieving  the  project’s  objectives 
Subpractices 

1 .  Establish  the  criteria  to  use  in  evaluating  process  alternatives  for  the 
project. 

:  Criteria  can  be  based  on  the  following: 
i  •  Quality  and  process  performance  objectives 

i  •  Availability  of  process  performance  data  and  the  relevance  of  the  data  to  evaluating  an 
;  alternative 

;  •  Familiarity  with  an  alternative  or  with  alternatives  similar  in  composition 
;  •  Existence  of  process  performance  models  that  can  be  used  in  evaluating  an  alternative 
;  •  Product  line  standards 
i  •  Project  lifecycle  models 
I  •  Stakeholder  requirements 
I  •  Laws  and  regulations 


2.  Identify  alternative  processes  and  subprocesses  for  the  project. 
Identifying  alternatives  can  include  one  or  more  of  the  following: 

•  Analyzing  organizational  process  performance  baselines  to  identify  candidate 
subprocesses  that  would  help  achieve  the  project's  quality  and  process  performance 
objectives 

•  Identifying  subprocesses  from  the  organization's  set  of  standard  processes  as  well  as 
tailored  processes  in  the  process  asset  library  that  can  help  to  achieve  the  objectives 

•  Identifying  processes  from  external  sources  (e.g.,  such  as  other  organizations, 
professional  conferences,  academic  research) 

•  Adjusting  the  level  or  depth  of  intensity  with  which  a  subprocess  is  applied  (as 
described  in  further  detail  in  a  subpractice  that  follows) 

Adjusting  the  level  or  depth  of  intensity  with  which  the  subprocesses  are  applied  can 
involve  the  following  choices: 

•  Number  and  type  of  peer  reviews  to  be  held  and  when 

•  Amount  of  effort  or  calendar  time  devoted  to  particular  tasks 

•  Number  and  selection  of  people  involved 

•  Skill  level  requirements  for  performing  specific  tasks 

•  Selective  application  of  specialized  construction  or  verification  techniques 

•  Reuse  decisions  and  associated  risk  mitigation  strategies 

•  The  product  and  process  attributes  to  be  measured 

•  Sampling  rate  for  management  data 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  using  organizational  process  assets  for  planning 
project  activities. 

3.  Analyze  the  interaction  of  alternative  subprocesses  to  understand 
relationships  among  the  subprocesses,  including  their  attributes. 
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An  analysis  of  the  interaction  will  provide  insight  into  the  relative  strengths  and 
weaknesses  of  particular  alternatives.  This  analysis  can  be  supported  by  a  calibration 
of  the  organization’s  process  performance  models  with  process  performance  data 
(e.g.,  as  characterized  in  process  performance  baselines). 

Additional  modeling  may  be  needed  if  existing  process  performance  models  cannot 
address  significant  relationships  among  the  alternative  subprocesses  under 
consideration  and  there  is  high  risk  of  not  achieving  objectives. 

4.  Evaluate  alternative  subprocesses  against  the  criteria. 

Use  historical  data,  process  performance  baselines,  and  process  performance  models 
as  appropriate  to  assist  in  evaluating  alternatives  against  the  criteria.  These 
evaluations  can  include  use  of  a  sensitivity  analysis  particularly  in  high  risk  situations. 

Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  evaiuating  aiternatives. 

5.  Select  the  alternative  subprocesses  that  best  meet  the  criteria. 

It  may  be  necessary  to  iterate  through  the  activities  described  in  the  previous 
subpractices  several  times  before  confidence  is  achieved  that  the  best  available 
alternatives  have  been  identified. 

6.  Evaluate  the  risk  of  not  achieving  the  project’s  quality  and  process 
performance  objectives. 

An  analysis  of  risk  associated  with  the  selected  alternative  defined  process  can  lead  to 
identifying  new  alternatives  to  be  evaluated,  as  well  as  areas  requiring  more 
management  attention. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  anaiyzing  risks. 

SP  1 .3  Select  Subprocesses  and  Attributes 

Select  subprocesses  and  attributes  critical  to  evaluating 
performance  and  that  help  to  achieve  the  project’s  quality  and 
process  performance  objectives. 

Some  subprocesses  are  critical  because  their  performance  significantly 
influences  or  contributes  to  achieving  the  project’s  objectives.  These 
subprocesses  may  be  good  candidates  for  monitoring  and  control  using 
statistical  and  other  quantitative  techniques  as  described  in  the  first  specific 
practice  of  the  second  specific  goal. 

Also,  some  attributes  of  these  subprocesses  can  serve  as  leading 
indicators  of  the  process  performance  to  expect  of  subprocesses  that  are 
further  downstream  and  can  be  used  to  assess  the  risk  of  not  achieving  the 
project’s  objectives  (e.g.,  by  using  process  performance  models). 

Subprocesses  and  attributes  that  play  such  critical  roles  may  have  already 
been  identified  as  part  of  the  analyses  described  in  the  previous  specific 
practice. 

For  small  projects,  and  other  circumstances  in  which  subprocess  data  may 
not  be  generated  frequently  enough  in  the  project  to  support  a  sufficiently 
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sensitive  statistical  inference,  it  may  still  be  possible  to  understand 
performance  by  examining  process  performance  across  similar  iterations, 
teams,  or  projects. 

Example  Work  Products 

1 .  Criteria  used  to  select  subprocesses  that  are  key  contributors  to 
achieving  the  project’s  objectives 

2.  Selected  subprocesses 

3.  Attributes  of  selected  subprocesses  that  help  in  predicting  future 
project  performance 

Subpractices 

1 .  Analyze  how  subprocesses,  their  attributes,  other  factors,  and  project 
performance  results  relate  to  each  other. 

A  root  cause  analysis,  sensitivity  analysis,  or  process  performance  model  can  help  to 
Identify  the  subprocesses  and  attributes  that  most  contribute  to  achieving  particular 
performance  results  (and  variation  In  performance  results)  or  that  are  useful  Indicators 
of  future  achievement  of  performance  results. 

Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  determining  causes  of  selected  outcomes. 

2.  Identify  criteria  to  be  used  in  selecting  subprocesses  that  are  key 
contributors  to  achieving  the  project’s  quality  and  process  performance 
objectives. 

:  Examples  of  criteria  used  to  select  subprocesses  Include  the  following: 

i  •  There  Is  a  strong  correlation  with  performance  results  that  are  addressed  In  the 
;  project's  objectives. 

i  •  Stable  performance  of  the  subprocess  Is  Important, 
i  •  Poor  subprocess  performance  Is  associated  with  major  risks  to  the  project. 

i  •  One  or  more  attributes  of  the  subprocess  serve  as  key  Inputs  to  process  performance 
i  models  used  In  the  project. 

;  •  The  subprocess  will  be  executed  frequently  enough  to  provide  sufficient  data  for 
i  analysis. 

3.  Select  subprocesses  using  the  identified  criteria. 

Historical  data,  process  performance  models,  and  process  performance  baselines  can 
help  In  evaluating  candidate  subprocesses  against  selection  criteria. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  evaluating  alternatives. 

4.  Identify  product  and  process  attributes  to  be  monitored. 

These  attributes  may  have  been  identified  as  part  of  performing  the  previous 
subpractices. 

Attributes  that  provide  insight  into  current  or  future  subprocess  performance  are 
candidates  for  monitoring,  whether  or  not  the  associated  subprocesses  are  under  the 
control  of  the  project.  Also,  some  of  these  same  attributes  may  serve  other  roles,  (e.g.. 
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to  help  in  monitoring  project  progress  and  performance  as  described  in  Project 
Monitoring  and  Control  [PMC]). 

;  Examples  of  product  and  process  attributes  include  the  following: 

;  •  Effort  consumed  to  perform  the  subprocess 

;  •  The  rate  at  which  the  subprocess  is  performed 

I  •  Cycle  time  for  process  elements  that  make  up  the  subprocess 

I  •  Resource  or  materials  consumed  as  input  to  the  subprocess 

I  •  Skill  level  of  the  staff  member  performing  the  subprocess 

I  •  Quality  of  the  work  environment  used  to  perform  the  subprocess 

I  •  Volume  of  outputs  of  the  subprocess  (e.g.,  intermediate  work  products) 

[  •  Quality  attributes  of  outputs  of  the  subprocess  (e.g.,  reliability,  testability) 


SP  1 .4  Select  Measures  and  Analytic  Techniques 

Select  measures  and  analytic  techniques  to  be  used  in  quantitative 
management. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  aligning  measurement  and  analysis  activities  and  providing 
measurement  results. 

Example  Work  Products 

1 .  Definitions  of  measures  and  analytic  techniques  to  be  used  in 
quantitative  management 

2.  Traceability  of  measures  back  to  the  project’s  quality  and  process 
performance  objectives 

3.  Quality  and  process  performance  objectives  for  selected  subprocesses 
and  their  attributes 

4.  Process  performance  baselines  and  models  for  use  by  the  project 
Subpractices 

1 .  Identify  common  measures  from  the  organizational  process  assets  that 
support  quantitative  management. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  organizational  process  assets. 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  establishing  performance  baselines  and 
models. 

Product  lines  or  other  stratification  criteria  can  categorize  common  measures. 

2.  Identify  additional  measures  that  may  be  needed  to  cover  critical 
product  and  process  attributes  of  the  selected  subprocesses. 

In  some  cases,  measures  can  be  research  oriented.  Such  measures  should  be 
explicitly  identified. 

3.  Identify  the  measures  to  be  used  in  managing  subprocesses. 
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When  selecting  measures,  keep  the  following  considerations  in  mind: 

•  Measures  that  aggregate  data  from  multiple  sources  (e.g.,  different 
processes,  input  sources,  environments)  or  over  time  (e.g.,  at  a  phase  level) 
can  mask  underlying  problems,  making  problem  identification  and  resolution 
difficult. 

•  For  short-term  projects,  it  may  be  necessary  to  aggregate  data  across  similar 
instances  of  a  process  to  enable  analysis  of  its  process  performance  while 
continuing  to  use  the  unaggregated  data  in  support  of  individual  projects. 

•  Selection  should  not  be  limited  to  progress  or  performance  measures  only. 
‘‘Analysis  measures”  (e.g.,  inspection  preparation  rates,  staff  member  skill 
levels,  path  coverage  in  testing)  may  provide  better  insight  into  process 
performance. 

4.  Specify  the  operational  definitions  of  measures,  their  collection  points 
in  subprocesses,  and  how  the  integrity  of  measures  will  be  determined. 

5.  Analyze  the  relationship  of  identified  measures  to  the  project  quality 
and  process  performance  objectives  and  derive  subprocess  quality  and 
process  performance  objectives  that  state  targets  (e.g.,  thresholds, 
ranges)  to  be  met  for  each  measured  attribute  of  each  selected 
subprocess. 

i  Examples  of  derived  subprocess  quality  and  process  performance  objectives  include 
I  the  following: 

I  •  Maintain  a  code  review  rate  between  75  to  100  lines  of  code  per  hour 
:  •  Keep  requirements  gathering  sessions  to  under  three  hours 
:  •  Keep  test  rate  over  a  specified  number  of  test  cases  per  day 
I  •  Maintain  rework  levels  below  a  specified  percent 
I  •  Maintain  productivity  in  generating  use  cases  per  day 
i  •  Keep  design  complexity  (fan-out  rate)  below  a  specified  threshold 


6.  Identify  the  statistical  and  other  quantitative  techniques  to  be  used  in 
quantitative  management. 

In  quantitative  management,  the  process  performance  of  selected  subprocesses  is 
analyzed  using  statistical  and  other  quantitative  techniques  that  help  to  characterize 
subprocess  variation,  identify  when  statistically  unexpected  behavior  occurs,  recognize 
when  variation  is  excessive,  and  investigate  why.  Examples  of  statistical  techniques 
that  can  be  used  in  the  analysis  of  process  performance  include  statistical  process 
control  charts,  regression  analysis,  analysis  of  variance,  and  time  series  analysis. 

The  project  can  benefit  from  analyzing  the  performance  of  subprocesses  not  selected 
for  their  impact  on  project  performance.  Statistical  and  other  quantitative  techniques 
can  be  identified  to  address  these  subprocesses  as  well. 

Statistical  and  other  quantitative  techniques  sometimes  involve  the  use  of  graphical 
displays  that  help  visualize  associations  among  the  data  and  results  of  analyses.  Such 
graphical  displays  can  help  visualize  process  performance  and  variation  over  time  (i.e., 
trends),  identify  problems  or  opportunities,  and  evaluate  the  effects  of  particular 
factors. 
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Examples  of  graphical  displays  include  the  following: 

•  Scatterplots 

•  Histograms 

•  Box  and  whiskers  plots 

•  Run  charts 

•  Ishikawa  diagrams 


:  Examples  of  other  techniques  used  to  analyze  process  performance  include  the 
I  following: 

:  •  Tally  sheets 

•  Classification  schemas  (e.g.,  Orthogonal  Defect  Classification) 


7.  Determine  what  process  performance  baselines  and  models  may  be 
needed  to  support  identified  analyses. 

In  some  situations,  the  set  of  baselines  and  models  provided  as  described  in 
Organizational  Process  Performance  may  be  inadequate  to  support  quantitative 
project  management.  This  situation  can  happen  when  the  objectives,  processes, 
stakeholders,  skill  levels,  or  environment  for  the  project  are  different  from  other 
projects  for  which  baselines  and  models  were  established. 

As  the  project  progresses,  data  from  the  project  can  serve  as  a  more  representative 
data  set  for  establishing  missing  or  a  project  specific  set  of  process  performance 
baselines  and  models. 

Hypothesis  testing  comparing  project  data  to  prior  historical  data  can  confirm  the  need 
to  establish  additional  baselines  and  models  specific  to  the  project. 

8.  Instrument  the  organizational  or  project  support  environment  to  support 
collection,  derivation,  and  analysis  of  measures. 

This  instrumentation  is  based  on  the  following: 

•  Description  of  the  organization's  set  of  standard  processes 

•  Description  of  the  project's  defined  process 

•  Capabilities  of  the  organizational  or  project  support  environment 

9.  Revise  measures  and  statistical  analysis  techniques  as  necessary. 
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SG  2 _ Quantitatively  Manage  the  Project _ 

The  project  is  quantitatively  managed. 

Quantitatively  managing  the  project  involves  the  use  of  statistical  and  other 
quantitative  techniques  to  do  the  following: 

•  Monitor  the  selected  subprocesses  using  statistical  and  other 
quantitative  techniques 

•  Determine  whether  or  not  the  project’s  quality  and  process  performance 
objectives  are  being  satisfied 

•  Perform  root  cause  analysis  of  selected  issues  to  address  deficiencies 

SP  2.1  Monitor  the  Performance  of  Selected  Subprocesses 

Monitor  the  performance  of  selected  subprocesses  using 
statistical  and  other  quantitative  techniques. 

The  intent  of  this  specific  practice  is  to  use  statistical  and  other  quantitative 
techniques  to  analyze  variation  in  subprocess  performance  and  to 
determine  actions  necessary  to  achieve  each  subprocess’s  quality  and 
process  performance  objectives. 

Example  Work  Products 

1 .  Natural  bounds  of  process  performance  for  each  selected  subprocess 
attribute 

2.  The  actions  needed  to  address  deficiencies  in  the  process  stability  or 
capability  of  each  selected  subprocess 

Subpractices 

1 .  Collect  data,  as  defined  by  the  selected  measures,  on  the 
subprocesses  as  they  execute. 

2.  Monitor  the  variation  and  stability  of  the  selected  subprocesses  and 
address  deficiencies. 

This  analysis  involves  evaluating  measurements  in  relation  to  the  natural  bounds 
calculated  for  each  selected  measure  and  identifying  outliers  or  other  signals  of 
potential  non-random  behavior,  determining  their  causes  and  preventing  or  mitigating 
the  effects  of  their  recurrence  (i.e.,  addressing  special  causes  of  variation). 

During  such  analysis,  be  sensitive  to  the  sufficiency  of  the  data  and  to  shifts  in  process 
performance  that  can  affect  the  ability  to  achieve  or  maintain  process  stability. 

Analytic  techniques  for  identifying  outliers  or  signals  include  statistical  process  control 
charts,  prediction  intervals,  and  analysis  of  variance.  Some  of  these  techniques  involve 
graphical  displays. 

Other  deficiencies  in  process  performance  to  consider  include  when  variation  is  too 
large  to  have  confidence  that  the  subprocess  is  stable,  or  too  great  to  assess  its 
capability  (next  subpractice)  of  achieving  the  objectives  established  for  each  selected 
attribute. 

3.  Monitor  the  capability  and  performance  of  the  selected  subprocesses 
and  address  deficiencies. 
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The  intent  of  this  subpractice  is  to  identify  what  actions  to  take  to  help  the  subprocess 
achieve  its  quality  and  process  performance  objectives.  Be  sure  that  the  subprocess 
performance  is  stable  relative  to  the  selected  measures  (previous  subpractice)  before 
comparing  its  capability  to  its  quality  and  process  performance  objectives. 

f. - 

;  Examples  of  actions  that  can  be  taken  when  the  performance  of  a  selected 
i  subprocess  fails  to  satisfy  its  objectives  include  the  following: 

i  •  Improving  the  implementation  of  the  existing  subprocess  to  reduce  its  variation  or 
;  improve  its  performance  (i.e.,  addressing  common  causes  of  variation) 

I  •  Identifying  and  implementing  an  alternative  subprocess  through  identifying  and 
;  adopting  new  process  elements,  subprocesses,  and  technologies  that  may  help  better 
;  align  with  objectives 

;  •  Identifying  risks  and  risk  mitigation  strategies  for  each  deficiency  in  subprocess 
I  capability 

;  •  Renegotiating  or  re-deriving  objectives  for  each  selected  attribute  of  a  subprocess  so 

I  that  they  can  be  met  by  the  subprocess 


Some  actions  can  involve  the  use  of  root  cause  analysis,  which  is  further  described  in 
SP2.3. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  managing  corrective  action  to  ciosure. 

SP  2.2  Manage  Project  Performance 

Manage  the  project  using  statistical  and  other  quantitative 
techniques  to  determine  whether  or  not  the  project’s  objectives  for 
quality  and  process  performance  will  be  satisfied. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  aiigning  measurement  and  analysis  activities  and  providing 
measurement  results. 

Refer  to  the  Organizational  Performance  Management  process  area  for 
more  information  about  managing  business  performance. 

This  specific  practice  is  project  focused  and  uses  multiple  inputs  to  predict  if 
the  project's  quality  and  process  performance  objectives  will  be  satisfied. 
Based  on  this  prediction,  risks  associated  with  not  meeting  the  project’s 
quality  and  process  performance  objectives  are  identified  and  managed, 
and  actions  to  address  deficiencies  are  defined  as  appropriate. 

Key  inputs  to  this  analysis  include  the  individual  subprocess  stability  and 
capability  data  derived  from  the  previous  specific  practice,  as  well  as 
performance  data  from  monitoring  other  subprocesses,  risks,  and  suppliers’ 
progress. 

Example  Work  Products 

1 .  Predictions  of  results  to  be  achieved  relative  to  the  project’s  quality  and 
process  performance  objectives 

2.  Graphical  displays  and  data  tabulations  for  other  subprocesses,  which 
support  quantitative  management 
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3.  Assessment  of  risks  of  not  achieving  the  project’s  quality  and  process 
performance  objectives 

4.  Actions  needed  to  address  deficiencies  in  achieving  project  objectives 
Subpractices 

1 .  Periodically  review  the  performance  of  subprocesses. 

Stability  and  capability  data  from  monitoring  selected  subprocesses,  as  described  In 
SP2.1 ,  are  a  key  Input  Into  understanding  the  project’s  overall  ability  to  meet  quality 
and  process  performance  objectives. 

In  addition,  subprocesses  not  selected  for  their  Impact  on  project  objectives  can  still 
create  problems  or  risks  for  the  project  and  thus  some  level  of  monitoring  for  these 
subprocesses  may  be  desired  as  well.  Analytic  techniques  Involving  the  use  of 
graphical  displays  can  also  prove  to  be  useful  to  understanding  subprocess 
performance. 

2.  Monitor  and  analyze  suppliers’  progress  toward  achieving  their  quality 
and  process  performance  objectives. 

3.  Periodically  review  and  analyze  actual  results  achieved  against 
established  interim  objectives. 

4.  Use  process  performance  models  calibrated  with  project  data  to 
assess  progress  toward  achieving  the  project’s  quality  and  process 
performance  objectives. 

Process  performance  models  are  used  to  assess  progress  toward  achieving  objectives 
that  cannot  be  measured  until  a  future  phase  In  the  project  lifecycle.  Objectives  can 
either  be  Interim  objectives  or  overall  objectives. 

^ - 

I  An  example  Is  the  use  of  process  performance  models  to  predict  the  latent  defects  In 

i  work  products  In  future  phases  or  In  the  delivered  product. 


Calibration  of  process  performance  models  Is  based  on  the  results  obtained  from 
performing  the  activities  described  In  the  previous  subpractices  and  specific  practices. 

5.  Identify  and  manage  risks  associated  with  achieving  the  project’s 
quality  and  process  performance  objectives. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  anaiyzing  risks  and  mitigating  risks. 

;  Example  sources  of  risks  Include  the  following: 

;  •  Subprocesses  having  Inadequate  performance  or  capability 
I  •  Suppliers  not  achieving  their  quality  and  process  performance  objectives 
I  •  Lack  of  visibility  Into  supplier  capability 

I  •  Inaccuracies  In  the  process  performance  models  used  for  predicting  performance 
I  •  Deficiencies  In  predicted  process  performance  (estimated  progress) 

:  •  Other  Identified  risks  associated  with  Identified  deficiencies 
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6.  Determine  and  implement  actions  needed  to  address  deficiencies  in 
achieving  the  project’s  quality  and  process  performance  objectives. 

The  intent  of  this  subpractice  is  to  identify  and  implement  the  right  set  of  actions, 
resources,  and  schedule  to  place  the  project  back  on  a  path  toward  achieving  its 
objectives. 

^ - 

I  Examples  of  actions  that  can  be  taken  to  address  deficiencies  in  achieving  the 

i  project’s  objectives  include  the  following: 

I  •  Changing  quality  and  process  performance  objectives  so  that  they  are  within  the 
;  expected  range  of  the  project's  defined  process 

I  •  Improving  the  implementation  of  the  project's  defined  process 

;  •  Adopting  new  subprocesses  and  technologies  that  have  the  potential  for  satisfying 
I  objectives  and  managing  associated  risks 

I  •  Identifying  the  risk  and  risk  mitigation  strategies  for  deficiencies 
I  •  Terminating  the  project 


Some  actions  can  involve  the  use  of  root  cause  analysis,  which  is  addressed  in  the 
next  specific  practice. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  managing  corrective  action  to  ciosure. 

When  corrective  actions  result  in  changes  to  attributes  or  measures  related  to 
adjustable  factors  in  a  process  performance  model,  the  model  can  be  used  to  predict 
the  effects  of  the  actions.  When  undertaking  critical  corrective  actions  in  high  risk 
situations,  a  process  performance  model  can  be  created  to  predict  the  effects  of  the 
change. 

SP  2.3  Perform  Root  Cause  Analysis 

Perform  root  cause  analysis  of  selected  issues  to  address 
deficiencies  in  achieving  the  project’s  quality  and  process 
performance  objectives. 

Issues  to  address  include  deficiencies  in  subprocess  stability  and  capability, 
and  deficiencies  in  project  performance  relative  to  its  objectives. 

Root  cause  analysis  of  selected  issues  is  best  performed  shortly  after  the 
problem  is  first  identified,  while  the  event  is  still  recent  enough  to  be 
carefully  investigated. 

The  formality  of  and  effort  required  for  a  root  cause  analysis  can  vary 
greatly  and  can  be  determined  by  such  factors  as  the  stakeholders  who  are 
involved;  the  risk  or  opportunity  that  is  present;  the  complexity  of  the 
situation;  the  frequency  with  which  the  situation  could  recur;  the  availability 
of  data,  baselines,  and  models  that  can  be  used  in  the  analysis;  and  how 
much  time  has  passed  since  the  events  triggering  the  deficiency. 

In  the  case  of  a  subprocess  that  exhibits  too  much  variation,  is  performed 
rarely,  and  involves  different  stakeholders,  it  could  take  weeks  or  months  to 
identify  root  causes. 
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Likewise,  the  actions  to  take  can  range  significantly  in  terms  of  effort  and 
time  needed  to  determine,  plan,  and  implement  them. 

It  is  often  difficult  to  know  how  much  time  is  needed  unless  an  initial 
analysis  of  the  deficiencies  is  undertaken. 

Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  identifying  causes  of  selected  outcomes  and  taking  action 
to  improve  process  performance. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more  information 
about  aligning  measurement  and  analysis  activities  and  providing 
measurement  results. 

Example  Work  Products 

1 .  Subprocess  and  project  performance  measurements  and  analyses 
(including  statistical  analyses)  recorded  in  the  organization’s 
measurement  repository 

2.  Graphical  displays  of  data  used  to  understand  subprocess  and  project 
performance  and  performance  trends 

3.  Identified  root  causes  and  potential  actions  to  take 
Subpractices 

1 .  Perform  root  cause  analysis,  as  appropriate,  to  diagnose  process 
performance  deficiencies. 

Process  performance  baselines  and  models  are  used  In  diagnosing  deficiencies; 
Identifying  possible  solutions;  predicting  future  project  and  process  performance;  and 
evaluating  potential  actions  as  appropriate. 

The  use  of  process  performance  models  In  predicting  future  project  and  process 
performance  is  described  in  a  subpractice  of  the  previous  specific  practice. 

2.  Identify  and  analyze  potential  actions. 

3.  Implement  selected  actions. 

4.  Assess  the  impact  of  the  actions  on  subprocess  performance. 

This  assessment  of  impact  can  include  an  evaluation  of  the  statistical  significance  of 
the  impacts  resulting  from  the  actions  taken  to  improve  process  performance. 
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REQUIREMENTS  DEVELOPMENT 

An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Requirements  Development  (RD)  is  to  elicit,  analyze,  and 
establish  customer,  product,  and  product  component  requirements. 


Introductory  Notes 


This  process  area  describes  three  types  of  requirements:  customer 
requirements,  product  requirements,  and  product  component  requirements. 
Taken  together,  these  requirements  address  the  needs  of  relevant 
stakeholders,  including  needs  pertinent  to  various  product  lifecycle  phases 
(e.g.,  acceptance  testing  criteria)  and  product  attributes  (e.g., 
responsiveness,  safety,  reliability,  maintainability).  Requirements  also 
address  constraints  caused  by  the  selection  of  design  solutions  (e.g., 
integration  of  commercial  off-the-shelf  products,  use  of  a  particular 
architecture  pattern). 

All  development  projects  have  requirements.  Requirements  are  the  basis 
for  design.  The  development  of  requirements  includes  the  following 
activities: 

•  Elicitation,  analysis,  validation,  and  communication  of  customer  needs, 
expectations,  and  constraints  to  obtain  prioritized  customer 
requirements  that  constitute  an  understanding  of  what  will  satisfy 
stakeholders 

•  Collection  and  coordination  of  stakeholder  needs 

•  Development  of  the  lifecycle  requirements  of  the  product 

•  Establishment  of  the  customer  functional  and  quality  attribute 
requirements 

•  Establishment  of  initial  product  and  product  component  requirements 
consistent  with  customer  requirements 

This  process  area  addresses  all  customer  requirements  rather  than  only 
product  level  requirements  because  the  customer  can  also  provide  specific 
design  requirements. 

Customer  requirements  are  further  refined  into  product  and  product 
component  requirements.  In  addition  to  customer  requirements,  product 
and  product  component  requirements  are  derived  from  the  selected  design 
solutions.  Throughout  the  process  areas,  where  the  terms  “product”  and 
“product  component”  are  used,  their  intended  meanings  also  encompass 
services,  service  systems,  and  their  components. 

Requirements  are  identified  and  refined  throughout  the  phases  of  the 
product  lifecycle.  Design  decisions,  subsequent  corrective  actions,  and 
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feedback  during  each  phase  of  the  product’s  lifecycle  are  analyzed  for 
impact  on  derived  and  allocated  requirements. 

The  Requirements  Development  process  area  includes  three  specific  goals. 
The  Develop  Customer  Requirements  specific  goal  addresses  defining  a 
set  of  customer  requirements  to  use  in  the  development  of  product 
requirements.  The  Develop  Product  Requirements  specific  goal  addresses 
defining  a  set  of  product  or  product  component  requirements  to  use  in  the 
design  of  products  and  product  components.  The  Analyze  and  Validate 
Requirements  specific  goal  addresses  the  analysis  of  customer,  product, 
and  product  component  requirements  to  define,  derive,  and  understand  the 
requirements.  The  specific  practices  of  the  third  specific  goal  are  intended 
to  assist  the  specific  practices  in  the  first  two  specific  goals.  The  processes 
associated  with  the  Requirements  Development  process  area  and 
processes  associated  with  the  Technical  Solution  process  area  can  interact 
recursively  with  one  another. 

Analyses  are  used  to  understand,  define,  and  select  the  requirements  at  all 
levels  from  competing  alternatives.  These  analyses  include  the  following: 

•  Analysis  of  needs  and  requirements  for  each  product  lifecycle  phase, 
including  needs  of  relevant  stakeholders,  the  operational  environment, 
and  factors  that  reflect  overall  customer  and  end-user  expectations  and 
satisfaction,  such  as  safety,  security,  and  affordability 

•  Development  of  an  operational  concept 

•  Definition  of  the  required  functionality  and  quality  attributes 

This  definition  of  required  functionality  and  quality  attributes  describes  what 
the  product  is  to  do.  (See  the  definition  of  “definition  of  required  functionality 
and  quality  attributes”  in  the  glossary.)  This  definition  can  include 
descriptions,  decompositions,  and  a  partitioning  of  the  functions  (or  in 
object  oriented  analysis  what  has  been  referred  to  as  “services”  or 
“methods”)  of  the  product. 

In  addition,  the  definition  specifies  design  considerations  or  constraints  on 
how  the  required  functionality  will  be  realized  in  the  product.  Quality 
attributes  address  such  things  as  product  availability;  maintainability; 
modifiability;  timeliness,  throughput,  and  responsiveness;  reliability; 
security;  and  scalability.  Some  quality  attributes  will  emerge  as 
architecturally  significant  and  thus  drive  the  development  of  the  product 
architecture. 

Such  analyses  occur  recursively  at  successively  more  detailed  layers  of  a 
product’s  architecture  until  sufficient  detail  is  available  to  enable  detailed 
design,  acquisition,  and  testing  of  the  product  to  proceed.  As  a  result  of  the 
analysis  of  requirements  and  the  operational  concept  (including 
functionality,  support,  maintenance,  and  disposal),  the  manufacturing  or 
production  concept  produces  more  derived  requirements,  including 
consideration  of  the  following: 

•  Constraints  of  various  types 

•  Technological  limitations 
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•  Cost  and  cost  drivers 

•  Time  constraints  and  schedule  drivers 

•  Risks 

•  Consideration  of  issues  implied  but  not  explicitly  stated  by  the  customer 
or  end  user 

•  Factors  introduced  by  the  developer’s  unique  business  considerations, 
regulations,  and  laws 

A  hierarchy  of  logical  entities  (e.g.,  functions  and  subfunctions,  object 
classes  and  subclasses;  processes;  other  architectural  entities)  is 
established  through  iteration  with  the  evolving  operational  concept. 
Requirements  are  refined,  derived,  and  allocated  to  these  logical  entities. 
Requirements  and  logical  entities  are  allocated  to  products,  product 
components,  people,  or  associated  processes.  In  the  case  of  iterative  or 
incremental  development,  the  requirements  are  also  allocated  to  iterations 
or  increments. 

Involvement  of  relevant  stakeholders  in  both  requirements  development 
and  analysis  gives  them  visibility  into  the  evolution  of  requirements.  This 
activity  continually  assures  them  that  the  requirements  are  being  properly 
defined. 

For  product  lines,  engineering  processes  (including  requirements 
development)  may  be  applied  to  at  least  two  levels  in  the  organization.  At 
an  organizational  or  product  line  level,  a  “commonality  and  variation 
analysis”  is  performed  to  help  elicit,  analyze,  and  establish  core  assets  for 
use  by  projects  within  the  product  line.  At  the  project  level,  these  core 
assets  are  then  used  as  per  the  product  line  production  plan  as  part  of  the 
project’s  engineering  activities. 

In  Agile  environments,  customer  needs  and  ideas  are  iteratively  elicited,  elaborated, 
analyzed,  and  validated.  Requirements  are  documented  in  forms  such  as  user  stories, 
scenarios,  use  cases,  product  backlogs,  and  the  results  of  iterations  (working  code  in  the 
case  of  software).  Which  requirements  will  be  addressed  in  a  given  iteration  is  driven  by  an 
assessment  of  risk  and  by  the  priorities  associated  with  what  is  left  on  the  product  backlog. 
What  details  of  requirements  (and  other  artifacts)  to  document  is  driven  by  the  need  for 
coordination  (among  team  members,  teams,  and  later  iterations)  and  the  risk  of  losing  what 
was  learned.  When  the  customer  is  on  the  team,  there  can  still  be  a  need  for  separate 
customer  and  product  documentation  to  allow  multiple  solutions  to  be  explored.  As  the 
solution  emerges,  responsibilities  for  derived  requirements  are  allocated  to  the  appropriate 
teams.  (See  “Interpreting  CMMI  When  Using  Agile  Approaches”  in  Part  I.) 


Related  Process  Areas 


Refer  to  the  Product  Integration  process  area  for  more  information  about 
ensuring  interface  compatibility. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
selecting  product  component  solutions  and  developing  the  design. 
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Refer  to  the  Validation  process  area  for  more  information  about  validating 
product  or  product  components. 

Refer  to  the  Verification  process  area  for  more  information  about  verifying 
selected  work  products. 

Refer  to  the  Configuration  Management  process  area  for  more  information 
about  tracking  and  controlling  changes. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  managing  requirements. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  analyzing  risks. 

Specific  Goai  and  Practice  Summary 

SG  1  Develop  Customer  Requirements 
SP1.1  Elicit  Needs 

SP  1 .2  T ransform  Stakeholder  Needs  into  Customer  Requirements 

SG  2  Develop  Product  Requirements 

SP  2.1  Estabiish  Product  and  Product  Component  Requirements 

SP  2.2  Allocate  Product  Component  Requirements 

SP  2.3  Identify  Interface  Requirements 

SG  3  Analyze  and  Validate  Requirements 

SP  3.1  Establish  Operational  Concepts  and  Scenarios 

SP  3.2  Establish  a  Definition  of  Required  Functionality  and  Quality  Attributes 

SP  3.3  Analyze  Requirements 

SP  3.4  Analyze  Requirements  to  Achieve  Balance 

SP  3.5  Validate  Requirements 

Specific  Practices  by  Goai 


SG  1 _ Develop  Customer  Requirements _ 

Stakeholder  needs,  expectations,  constraints,  and  interfaces  are  collected  and 
translated  into  customer  requirements. 

The  needs  of  stakeholders  (e.g.,  customers,  end  users,  suppliers,  builders, 
testers,  manufacturers,  logistics  support  staff)  are  the  basis  for  determining 
customer  requirements.  The  stakeholder  needs,  expectations,  constraints, 
interfaces,  operational  concepts,  and  product  concepts  are  analyzed, 
harmonized,  refined,  and  elaborated  for  translation  into  a  set  of  customer 
requirements. 

Frequently,  stakeholder  needs,  expectations,  constraints,  and  interfaces  are 
poorly  identified  or  conflicting.  Since  stakeholder  needs,  expectations, 
constraints,  and  limitations  should  be  clearly  identified  and  understood,  an 
iterative  process  is  used  throughout  the  life  of  the  project  to  accomplish  this 
objective.  To  facilitate  the  required  interaction,  a  surrogate  for  the  end  user 
or  customer  is  frequently  involved  to  represent  their  needs  and  help  resolve 
conflicts.  The  customer  relations  or  marketing  part  of  the  organization  as 
well  as  members  of  the  development  team  from  disciplines  such  as  human 
engineering  or  support  can  be  used  as  surrogates.  Environmental,  legal. 


328 


Requirements  Development  (RD) 


CMMI  for  Development,  Version  1.3 


and  other  constraints  should  be  considered  when  creating  and  resolving  the 
set  of  customer  requirements. 

SP1.1  Elicit  Needs 

Elicit  stakeholder  needs,  expectations,  constraints,  and  interfaces 
for  all  phases  of  the  product  lifecycle. 

Eliciting  goes  beyond  collecting  requirements  by  proactively  identifying 
additional  requirements  not  explicitly  provided  by  customers.  Additional 
requirements  should  address  the  various  product  lifecycle  activities  and 
their  impact  on  the  product. 

i  Examples  of  techniques  to  elicit  needs  include  the  following: 
i  •  Technology  demonstrations 

:  •  Interface  control  working  groups 

I  •  Technical  control  working  groups 

I  •  Interim  project  reviews 

i  •  Questionnaires,  interviews,  and  scenarios  (operational,  sustainment,  and  development) 
i  obtained  from  end  users 

:  •  Operational,  sustainment,  and  development  walkthroughs  and  end-user  task  analysis 
I  •  Quality  attribute  elicitation  workshops  with  stakeholders 
;  •  Prototypes  and  models 

i  •  Brainstorming 

;  •  Quality  Function  Deployment 

i  •  Market  surveys 

:  •  Beta  testing 

I  •  Extraction  from  sources  such  as  documents,  standards,  or  specifications 
;  •  Observation  of  existing  products,  environments,  and  workflow  patterns 
i  •  Use  cases 

;  •  User  stories 

i  •  Delivering  small  incremental  ‘‘vertical  slices”  of  product  functionality 

:  •  Business  case  analysis 

I  •  Reverse  engineering  (for  legacy  products) 

;  •  Customer  satisfaction  surveys 
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I  Examples  of  sources  of  requirements  that  may  not  be  identified  by  the  customer  include  the 
i  following: 

i  •  Business  policies 

i  •  Standards 

i  •  Previous  architectural  design  decisions  and  principles 

I  •  Business  environmental  requirements  (e.g.,  laboratories,  testing  and  other  facilities, 

;  information  technology  infrastructure) 
i  •  Technology 

;  •  Legacy  products  or  product  components  (reuse  product  components) 
i  •  Regulatory  statutes 


Example  Work  Products 

1 .  Results  of  requirements  elicitation  activities 
Subpractices 

1 .  Engage  relevant  stakeholders  using  methods  for  eliciting  needs, 
expectations,  constraints,  and  external  interfaces. 

SP  1.2  Transform  Stakeholder  Needs  into  Customer  Requirements 

Transform  stakeholder  needs,  expectations,  constraints,  and 
interfaces  into  prioritized  customer  requirements. 

The  various  inputs  from  the  relevant  stakeholders  should  be  consolidated, 
missing  information  should  be  obtained,  and  conflicts  should  be  resolved  as 
customer  requirements  are  developed  and  prioritized.  The  customer 
requirements  can  include  needs,  expectations,  and  constraints  with  regard 
to  verification  and  validation. 

In  some  situations,  the  customer  provides  a  set  of  requirements  to  the 
project,  or  the  requirements  exist  as  an  output  of  a  previous  project's 
activities.  In  these  situations,  the  customer  requirements  could  conflict  with 
the  relevant  stakeholders'  needs,  expectations,  constraints,  and  interfaces 
and  will  need  to  be  transformed  into  the  recognized  set  of  customer 
requirements  after  appropriate  resolution  of  conflicts. 

Relevant  stakeholders  representing  all  phases  of  the  product's  lifecycle 
should  include  business  as  well  as  technical  functions.  In  this  way, 
concepts  for  all  product  related  lifecycle  processes  are  considered 
concurrently  with  the  concepts  for  the  products.  Customer  requirements 
result  from  informed  decisions  on  the  business  as  well  as  technical  effects 
of  their  requirements. 

Example  Work  Products 

1 .  Prioritized  customer  requirements 

2.  Customer  constraints  on  the  conduct  of  verification 

3.  Customer  constraints  on  the  conduct  of  validation 
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Subpractices 

1 .  Translate  stakeholder  needs,  expectations,  constraints,  and  interfaces 
into  documented  customer  requirements. 

2.  Establish  and  maintain  a  prioritization  of  customer  functional  and 
quality  attribute  requirements. 

Having  prioritized  customer  requirements  heips  to  determine  project,  iteration,  or 
increment  scope.  This  prioritization  ensures  that  functionai  and  quaiity  attribute 
requirements  criticai  to  the  customer  and  other  stakehoiders  are  addressed  quickiy. 

3.  Define  constraints  for  verification  and  validation. 

SG  2 _ Develop  Product  Requirements _ 

Customer  requirements  are  refined  and  eiaborated  to  deveiop  product  and 
product  component  requirements. 

Customer  requirements  are  analyzed  in  conjunction  with  the  development 
of  the  operational  concept  to  derive  more  detailed  and  precise  sets  of 
requirements  called  “product  and  product  component  requirements.” 

Product  and  product  component  requirements  address  the  needs 
associated  with  each  product  lifecycle  phase.  Derived  requirements  arise 
from  constraints;  consideration  of  issues  implied  but  not  explicitly  stated  in 
the  customer  requirements  baseline;  factors  introduced  by  the  selected 
architecture,  product  lifecycle,  and  design;  and  the  developer’s  unique 
business  considerations.  The  requirements  are  reexamined  with  each 
successive,  lower  level  set  of  requirements  and  architecture,  and  the 
preferred  product  concept  is  refined. 

The  requirements  are  allocated  to  product  functions  and  product 
components  including  objects,  people,  and  processes.  In  the  case  of 
iterative  or  incremental  development,  the  requirements  are  also  allocated  to 
iterations  or  increments  based  on  customer  priorities,  technology  issues, 
and  project  objectives.  The  traceability  of  requirements  to  functions, 
objects,  tests,  issues,  or  other  entities  is  documented.  The  allocated 
requirements  and  functions  (or  other  logical  entities)  are  the  basis  for  the 
synthesis  of  the  technical  solution;  however,  as  the  architecture  is  defined 
or  emerges,  it  serves  as  the  ultimate  basis  for  directing  the  allocation  of 
requirements  to  the  solution.  As  internal  components  are  developed, 
additional  interfaces  are  defined  and  interface  requirements  are 
established. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  maintaining  bidirectionai  traceabiiity  of  requirements. 

SP  2.1  Establish  Product  and  Product  Component  Requirements 

Estabiish  and  maintain  product  and  product  component 
requirements,  which  are  based  on  the  customer  requirements. 

The  customer  functional  and  quality  attribute  requirements  can  be 
expressed  in  the  customer’s  terms  and  can  be  nontechnical  descriptions. 
The  product  requirements  are  the  expression  of  these  requirements  in 
technical  terms  that  can  be  used  for  design  decisions.  An  example  of  this 
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translation  is  found  in  the  first  House  of  Quality  Function  Deployment,  which 
maps  customer  desires  into  technical  parameters.  For  instance,  “solid 
sounding  door”  may  be  mapped  to  size,  weight,  fit,  dampening,  and 
resonant  frequencies. 

Product  and  product  component  requirements  address  the  satisfaction  of 
customer,  business,  and  project  objectives  and  associated  attributes,  such 
as  effectiveness  and  affordability. 

Derived  requirements  also  address  the  needs  of  other  lifecycle  phases 
(e.g.,  production,  operations,  disposal)  to  the  extent  compatible  with 
business  objectives. 

The  modification  of  requirements  due  to  approved  requirement  changes  is 
covered  by  the  “maintain”  aspect  of  this  specific  practice;  whereas,  the 
administration  of  requirement  changes  is  covered  by  the  Requirements 
Management  process  area. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  managing  requirements. 

Example  Work  Products 

1 .  Derived  requirements 

2.  Product  requirements 

3.  Product  component  requirements 

4.  Architectural  requirements,  which  specify  or  constrain  the  relationships 
among  product  components 

Subpractices 

1 .  Develop  requirements  in  technical  terms  necessary  for  product  and 
product  component  design. 

2.  Derive  requirements  that  result  from  design  decisions. 

Refer  to  the  Technicai  Soiution  process  area  for  more  information 
about  seiecting  product  component  soiutions  and  deveioping  the 
design. 

Selection  of  a  technology  brings  with  it  additional  requirements.  For  instance,  use  of 
electronics  requires  additional  technology  specific  requirements  such  as 
electromagnetic  interference  limits. 

Architectural  decisions,  such  as  selection  of  architecture  patterns,  introduce  additional 
derived  requirements  for  product  components.  For  example,  the  Layers  Pattern  will 
constrain  dependencies  between  certain  product  components. 

3.  Develop  architectural  requirements  capturing  critical  quality  attributes 
and  quality  attribute  measures  necessary  for  establishing  the  product 
architecture  and  design. 
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Examples  of  quality  attribute  measures  include  the  following: 

•  Respond  within  1  second 

•  System  is  available  99%  of  the  time 

•  Implement  a  change  with  no  more  than  one  staff  week  of  effort 


4.  Establish  and  maintain  relationships  between  requirements  for 

consideration  during  change  management  and  requirements  allocation. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  maintaining  bidirectionai  traceabiiity  of  requirements. 

Relationships  between  requirements  can  aid  in  evaluating  the  impact  of  changes. 

SP  2.2  Allocate  Product  Component  Requirements 

Allocate  the  requirements  for  each  product  component. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
selecting  product  component  solutions. 

The  product  architecture  provides  the  basis  for  allocating  product 
requirements  to  product  components.  The  requirements  for  product 
components  of  the  defined  solution  include  allocation  of  product 
performance;  design  constraints;  and  fit,  form,  and  function  to  meet 
requirements  and  facilitate  production.  In  cases  where  a  higher  level 
requirement  specifies  a  quality  attribute  that  will  be  the  responsibility  of 
more  than  one  product  component,  the  quality  attribute  can  sometimes  be 
partitioned  for  unique  allocation  to  each  product  component  as  a  derived 
requirement,  however,  other  times  the  shared  requirement  should  instead 
be  allocated  directly  to  the  architecture.  For  example,  allocation  of  shared 
requirements  to  the  architecture  would  describe  how  a  performance 
requirement  (e.g.,  on  responsiveness)  is  budgeted  among  components  so 
as  to  account  in  an  end-to-end  manner  for  realization  of  the  requirement. 
This  concept  of  shared  requirements  can  extend  to  other  architecturally 
significant  quality  attributes  (e.g.,  security,  reliability). 

Example  Work  Products 

1 .  Requirement  allocation  sheets 

2.  Provisional  requirement  allocations 

3.  Design  constraints 

4.  Derived  requirements 

5.  Relationships  among  derived  requirements 
Subpractices 

1 .  Allocate  requirements  to  functions. 

2.  Allocate  requirements  to  product  components  and  the  architecture. 

3.  Allocate  design  constraints  to  product  components  and  the 
architecture. 

4.  Allocate  requirements  to  delivery  increments. 
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5.  Document  relationships  among  allocated  requirements. 

Relationships  include  dependencies  in  which  a  change  in  one  requirement  can  affect 
other  requirements. 

SP  2.3  Identify  Interface  Requirements 

Identify  interface  requirements. 

Interfaces  between  functions  (or  between  objects  or  other  logical  entities) 
are  identified.  Interfaces  can  drive  the  development  of  alternative  solutions 
described  in  the  Technical  Solution  process  area. 

Refer  to  the  Product  Integration  process  area  for  more  information  about 
ensuring  interface  compatibility. 

Interface  requirements  between  products  or  product  components  identified 
in  the  product  architecture  are  defined.  They  are  controlled  as  part  of 
product  and  product  component  integration  and  are  an  integral  part  of  the 
architecture  definition. 

Example  Work  Products 

1 .  Interface  requirements 

Subpractices 

1 .  Identify  interfaces  both  external  to  the  product  and  internal  to  the 
product  (e.g.,  between  functional  partitions  or  objects). 

As  the  design  progresses,  the  product  architecture  will  be  altered  by  technical  solution 
processes,  creating  new  interfaces  between  product  components  and  components 
external  to  the  product. 

Interfaces  with  product  related  lifecycle  processes  should  also  be  identified. 

:  Examples  of  these  interfaces  include  interfaces  with  test  equipment,  transportation 
;  systems,  support  systems,  and  manufacturing  facilities. 

2.  Develop  the  requirements  for  the  identified  interfaces. 

Refer  to  the  Technical  Solution  process  area  for  more  information 
about  designing  interfaces  using  criteria. 

Requirements  for  interfaces  are  defined  in  terms  such  as  origination,  destination, 
stimulus,  data  characteristics  for  software,  and  electrical  and  mechanical 
characteristics  for  hardware. 

SG  3  Analyze  and  Validate  Requirements 

The  requirements  are  analyzed  and  validated. 

The  specific  practices  of  the  Analyze  and  Validate  Requirements  specific 
goal  support  the  development  of  the  requirements  in  both  the  Develop 
Customer  Requirements  specific  goal  and  the  Develop  Product 
Requirements  specific  goal.  The  specific  practices  associated  with  this 
specific  goal  cover  analyzing  and  validating  the  requirements  with  respect 
to  the  end  user’s  intended  environment. 


334 


Requirements  Development  (RD) 


CMMI  for  Development,  Version  1.3 


Analyses  are  performed  to  determine  what  impact  the  intended  operational 
environment  will  have  on  the  ability  to  satisfy  the  stakeholders’  needs, 
expectations,  constraints,  and  interfaces.  Considerations,  such  as 
feasibility,  mission  needs,  cost  constraints,  potential  market  size,  and 
acquisition  strategy,  should  all  be  taken  into  account,  depending  on  the 
product  context.  Architecturally  significant  quality  attributes  are  identified 
based  on  mission  and  business  drivers.  A  definition  of  required  functionality 
and  quality  attributes  is  also  established.  All  specified  usage  modes  for  the 
product  are  considered. 

The  objectives  of  the  analyses  are  to  determine  candidate  requirements  for 
product  concepts  that  will  satisfy  stakeholder  needs,  expectations,  and 
constraints  and  then  to  translate  these  concepts  into  requirements.  In 
parallel  with  this  activity,  the  parameters  that  will  be  used  to  evaluate  the 
effectiveness  of  the  product  are  determined  based  on  customer  input  and 
the  preliminary  product  concept. 

Requirements  are  validated  to  increase  the  probability  that  the  resulting 
product  will  perform  as  intended  in  the  use  environment. 

SP  3.1  Establish  Operational  Concepts  and  Scenarios 

Establish  and  maintain  operational  concepts  and  associated 
scenarios. 

A  scenario  is  typically  a  sequence  of  events  that  may  occur  in  the 
development,  use,  or  sustainment  of  the  product,  which  is  used  to  make 
explicit  some  of  the  functional  or  quality  attribute  needs  of  the  stakeholders. 
In  contrast,  an  operational  concept  for  a  product  usually  depends  on  both 
the  design  solution  and  the  scenario.  For  example,  the  operational  concept 
for  a  satellite  based  communications  product  is  quite  different  from  one 
based  on  landlines.  Since  the  alternative  solutions  have  not  usually  been 
defined  when  preparing  the  initial  operational  concepts,  conceptual 
solutions  are  developed  for  use  when  analyzing  the  requirements.  The 
operational  concepts  are  refined  as  solution  decisions  are  made  and  lower 
level  detailed  requirements  are  developed. 

Just  as  a  design  decision  for  a  product  can  become  a  requirement  for  a 
product  component,  the  operational  concept  can  become  the  scenarios 
(requirements)  for  product  components.  Operational  concepts  and 
scenarios  are  evolved  to  facilitate  the  selection  of  product  component 
solutions  that,  when  implemented,  will  satisfy  the  intended  use  of  the 
product  or  facilitate  its  development  and  sustainment.  Operational  concepts 
and  scenarios  document  the  interaction  of  the  product  components  with  the 
environment,  end  users,  and  other  product  components,  regardless  of 
engineering  discipline.  They  should  be  documented  for  all  modes  and 
states  within  operations,  product  development,  deployment,  delivery, 
support  (including  maintenance  and  sustainment),  training,  and  disposal. 

Scenarios  can  be  developed  to  address  operational,  sustainment, 
development,  or  other  event  sequences. 
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Example  Work  Products 

1 .  Operational  concept 

2.  Product  or  product  component  development,  installation,  operational, 
maintenance,  and  support  concepts 

3.  Disposal  concepts 

4.  Use  cases 

5.  Timeline  scenarios 

6.  New  requirements 
Subpractices 

1 .  Develop  operational  concepts  and  scenarios  that  include  operations, 
installation,  development,  maintenance,  support,  and  disposal  as 
appropriate. 

Identify  and  develop  scenarios,  consistent  with  the  level  of  detail  in  the  stakeholder 
needs,  expectations,  and  constraints  in  which  the  proposed  product  or  product 
component  is  expected  to  operate. 

Augment  scenarios  with  quality  attribute  considerations  for  the  functions  (or  other 
logical  entities)  described  in  the  scenario. 

2.  Define  the  environment  in  which  the  product  or  product  component  will 
operate,  including  boundaries  and  constraints. 

3.  Review  operational  concepts  and  scenarios  to  refine  and  discover 
requirements. 

Operational  concept  and  scenario  development  is  an  iterative  process.  The  reviews 
should  be  held  periodically  to  ensure  that  they  agree  with  the  requirements.  The 
review  can  be  in  the  form  of  a  walkthrough. 

4.  Develop  a  detailed  operational  concept,  as  products  and  product 
components  are  selected,  that  defines  the  interaction  of  the  product, 
the  end  user,  and  the  environment,  and  that  satisfies  the  operational, 
maintenance,  support,  and  disposal  needs. 

SP  3.2  Establish  a  Definition  of  Required  Functionality  and  Quality  Attributes 

Establish  and  maintain  a  definition  of  required  functionality  and 
quality  attributes. 

One  approach  to  defining  required  functionality  and  quality  attributes  is  to 
analyze  scenarios  using  what  some  have  called  a  “functional  analysis”  to 
describe  what  the  product  is  intended  to  do.  This  functional  description  can 
include  actions,  sequence,  inputs,  outputs,  or  other  information  that 
communicates  the  manner  in  which  the  product  will  be  used.  The  resulting 
description  of  functions,  logical  groupings  of  functions,  and  their  association 
with  requirements  is  referred  to  as  a  functional  architecture.  (See  the 
definitions  of  “functional  analysis”  and  “functional  architecture”  in  the 
glossary.) 
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Such  approaches  have  evolved  in  recent  years  through  the  introduction  of 
architecture  description  languages,  methods,  and  tools  to  more  fully 
address  and  characterize  the  quality  attributes,  allowing  a  richer  (e.g.,  multi¬ 
dimensional)  specification  of  constraints  on  how  the  defined  functionality 
will  be  realized  in  the  product,  and  facilitating  additional  analyses  of  the 
requirements  and  technical  solutions.  Some  quality  attributes  will  emerge 
as  architecturally  significant  and  thus  drive  the  development  of  the  product 
architecture.  These  quality  attributes  often  reflect  cross-cutting  concerns 
that  may  not  be  allocatable  to  lower  level  elements  of  a  solution.  A  clear 
understanding  of  the  quality  attributes  and  their  importance  based  on 
mission  or  business  needs  is  an  essential  input  to  the  design  process. 

Example  Work  Products 

1 .  Definition  of  required  functionality  and  quality  attributes 

2.  Functional  architecture 

3.  Activity  diagrams  and  use  cases 

4.  Object  oriented  analysis  with  services  or  methods  identified 

5.  Architecturally  significant  quality  attribute  requirements 
Subpractices 

1 .  Determine  key  mission  and  business  drivers. 

2.  Identify  desirable  functionality  and  quality  attributes. 

Functionality  and  quality  attributes  can  be  identified  and  defined  through  an  analysis  of 
various  scenarios  with  relevant  stakeholders  as  described  in  the  previous  specific 
practice. 

3.  Determine  architecturally  significant  quality  attributes  based  on  key 
mission  and  business  drivers. 

4.  Analyze  and  quantify  functionality  required  by  end  users. 

This  analysis  can  involve  considering  the  sequencing  of  time  critical  functions. 

5.  Analyze  requirements  to  identify  logical  or  functional  partitions  (e.g., 
subfunctions). 

6.  Partition  requirements  into  groups,  based  on  established  criteria  (e.g., 
similar  functionality,  similar  quality  attribute  requirements,  coupling),  to 
facilitate  and  focus  the  requirements  analysis. 

7.  Allocate  customer  requirements  to  functional  partitions,  objects, 
people,  or  support  elements  to  support  the  synthesis  of  solutions. 

8.  Allocate  requirements  to  functions  and  subfunctions  (or  other  logical 
entities). 

SP  3.3  Analyze  Requirements 

Analyze  requirements  to  ensure  that  they  are  necessary  and 
sufficient 
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In  light  of  the  operational  concept  and  scenarios,  the  requirements  for  one 
level  of  the  product  hierarchy  are  analyzed  to  determine  whether  they  are 
necessary  and  sufficient  to  meet  the  objectives  of  higher  levels  of  the 
product  hierarchy.  The  analyzed  requirements  then  provide  the  basis  for 
more  detailed  and  precise  requirements  for  lower  levels  of  the  product 
hierarchy. 

As  requirements  are  defined,  their  relationship  to  higher  level  requirements 
and  the  higher  level  definition  of  required  functionality  and  quality  attributes 
should  be  understood.  Also,  the  key  requirements  used  to  track  progress 
are  determined.  For  instance,  the  weight  of  a  product  or  size  of  a  software 
product  can  be  monitored  through  development  based  on  its  risk  or  its 
criticality  to  the  customer. 

Refer  to  the  Verification  process  area  for  more  information  about 
estabiishing  verification  procedures  and  criteria. 

Example  Work  Products 

1 .  Requirements  defects  reports 

2.  Proposed  requirements  changes  to  resolve  defects 

3.  Key  requirements 

4.  Technical  performance  measures 
Subpractices 

1 .  Analyze  stakeholder  needs,  expectations,  constraints,  and  external 
interfaces  to  organize  them  into  related  subjects  and  remove  conflicts. 

2.  Analyze  requirements  to  determine  whether  they  satisfy  the  objectives 
of  higher  level  requirements. 

3.  Analyze  requirements  to  ensure  that  they  are  complete,  feasible, 
realizable,  and  verifiable. 

While  design  determines  the  feasibility  of  a  particular  solution,  this  subpractice 
addresses  knowing  which  requirements  affect  feasibility. 

4.  Identify  key  requirements  that  have  a  strong  influence  on  cost, 
schedule,  performance,  or  risk. 

5.  Identify  technical  performance  measures  that  will  be  tracked  during  the 
development  effort. 

Refer  to  the  Measurement  and  Anaiysis  process  area  for  more 
information  about  deveioping  and  sustaining  a  measurement  capabiiity 
used  to  support  management  information  needs. 

6.  Analyze  operational  concepts  and  scenarios  to  refine  the  customer 
needs,  constraints,  and  interfaces  and  to  discover  new  requirements. 

This  analysis  can  result  in  more  detailed  operational  concepts  and  scenarios  as  well 
as  supporting  the  derivation  of  new  requirements. 


338 


Requirements  Development  (RD) 


CMMI  for  Development,  Version  1.3 


SP  3.4  Analyze  Requirements  to  Achieve  Balance 

Analyze  requirements  to  balance  stakeholder  needs  and 
constraints. 

Stakeholder  needs  and  constraints  can  address  such  things  as  cost, 
schedule,  product  or  project  performance,  functionality,  priorities,  reusable 
components,  maintainability,  or  risk. 

Example  Work  Products 

1 .  Assessment  of  risks  related  to  requirements 
Subpractices 

1 .  Use  proven  models,  simulations,  and  prototyping  to  analyze  the 
balance  of  stakeholder  needs  and  constraints. 

Results  of  the  analyses  can  be  used  to  reduce  the  cost  of  the  product  and  the  risk  in 
developing  the  product. 

2.  Perform  a  risk  assessment  on  the  requirements  and  definition  of 
required  functionality  and  quality  attributes. 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  anaiyzing  risks. 

3.  Examine  product  lifecycle  concepts  for  impacts  of  requirements  on 
risks. 

4.  Assess  the  impact  of  the  architecturally  significant  quality  attribute 
requirements  on  the  product  and  product  development  costs  and  risks. 

When  the  impact  of  requirements  on  costs  and  risks  seems  to  outweigh  the  perceived 
benefit,  relevant  stakeholders  should  be  consulted  to  determine  what  changes  may  be 
needed. 

As  an  example,  a  really  tight  response  time  requirement  or  a  high  availability 
requirement  could  prove  expensive  to  implement.  Perhaps  the  requirement  could  be 
relaxed  once  the  impacts  (e.g.,  on  cost)  are  understood. 

SP  3.5  Validate  Requirements 

Validate  requirements  to  ensure  the  resulting  product  will  perform 
as  intended  in  the  end  user's  environment 

Requirements  validation  is  performed  early  in  the  development  effort  with 
end  users  to  gain  confidence  that  the  requirements  are  capable  of  guiding  a 
development  that  results  in  successful  final  validation.  This  activity  should 
be  integrated  with  risk  management  activities.  Mature  organizations  will 
typically  perform  requirements  validation  in  a  more  sophisticated  way  using 
multiple  techniques  and  will  broaden  the  basis  of  the  validation  to  include 
other  stakeholder  needs  and  expectations. 
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Examples  of  techniques  used  for  requirements  validation  include  the  following: 

•  Analysis 

•  Simulations 

•  Prototyping 

•  Demonstrations 


Example  Work  Products 

1 .  Record  of  analysis  methods  and  results 

Subpractices 

1 .  Analyze  the  requirements  to  determine  the  risk  that  the  resulting 
product  will  not  perform  appropriately  in  its  intended  use  environment. 

2.  Explore  the  adequacy  and  completeness  of  requirements  by 
developing  product  representations  (e.g.,  prototypes,  simulations, 
models,  scenarios,  storyboards)  and  by  obtaining  feedback  about  them 
from  relevant  stakeholders. 

Refer  to  the  Validation  process  area  for  more  information  about 
preparing  for  validation  and  validating  product  or  product  components. 

3.  Assess  the  design  as  it  matures  in  the  context  of  the  requirements 
validation  environment  to  identify  validation  issues  and  expose 
unstated  needs  and  customer  requirements. 
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REQUIREMENTS  MANAGEMENT 


A  Project  Management  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Requirements  Management  (REQM)  is  to  manage 
requirements  of  the  project’s  products  and  product  components  and  to 
ensure  alignment  between  those  requirements  and  the  project’s  plans  and 
work  products. 


Introductory  Notes 


Requirements  management  processes  manage  all  requirements  received 
or  generated  by  the  project,  including  both  technical  and  nontechnical 
requirements  as  well  as  requirements  levied  on  the  project  by  the 
organization. 

In  particular,  if  the  Requirements  Development  process  area  is 
implemented,  its  processes  will  generate  product  and  product  component 
requirements  that  will  also  be  managed  by  the  requirements  management 
processes. 

Throughout  the  process  areas,  where  the  terms  “product”  and  “product 
component”  are  used,  their  intended  meanings  also  encompass  services, 
service  systems,  and  their  components. 

When  the  Requirements  Management,  Requirements  Development,  and 
Technical  Solution  process  areas  are  all  implemented,  their  associated 
processes  can  be  closely  tied  and  be  performed  concurrently. 

The  project  takes  appropriate  steps  to  ensure  that  the  set  of  approved 
requirements  is  managed  to  support  the  planning  and  execution  needs  of 
the  project.  When  a  project  receives  requirements  from  an  approved 
requirements  provider,  these  requirements  are  reviewed  with  the 
requirements  provider  to  resolve  issues  and  prevent  misunderstanding 
before  requirements  are  incorporated  into  project  plans.  Once  the 
requirements  provider  and  the  requirements  receiver  reach  an  agreement, 
commitment  to  the  requirements  is  obtained  from  project  participants.  The 
project  manages  changes  to  requirements  as  they  evolve  and  identifies 
inconsistencies  that  occur  among  plans,  work  products,  and  requirements. 

Part  of  managing  requirements  is  documenting  requirements  changes  and 
their  rationale  and  maintaining  bidirectional  traceability  between  source 
requirements,  all  product  and  product  component  requirements,  and  other 
specified  work  products.  (See  the  definition  of  “bidirectional  traceability”  in 
the  glossary.) 

All  projects  have  requirements.  In  the  case  of  maintenance  activities, 
changes  are  based  on  changes  to  the  existing  requirements,  design,  or 
implementation.  In  projects  that  deliver  increments  of  product  capability,  the 
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changes  can  also  be  due  to  evolving  customer  needs,  technology 
maturation  and  obsolescence,  and  standards  evolution.  In  both  cases,  the 
requirements  changes,  if  any,  might  be  documented  in  change  requests 
from  the  customer  or  end  users,  or  they  might  take  the  form  of  new 
requirements  received  from  the  requirements  development  process. 
Regardless  of  their  source  or  form,  activities  that  are  driven  by  changes  to 
requirements  are  managed  accordingly. 

;  In  Agile  environments,  requirements  are  communicated  and  tracked  through  mechanisms 
i  such  as  product  backlogs,  story  cards,  and  screen  mock-ups.  Commitments  to  requirements 
I  are  either  made  collectively  by  the  team  or  an  empowered  team  leader.  Work  assignments 
i  are  regularly  (e.g.,  daily,  weekly)  adjusted  based  on  progress  made  and  as  an  improved 
i  understanding  of  the  requirements  and  solution  emerge.  Traceability  and  consistency  across 
;  requirements  and  work  products  is  addressed  through  the  mechanisms  already  mentioned 
;  as  well  as  during  start-of-iteration  or  end-of-iteration  activities  such  as  "retrospectives”  and 
I  "demo  days.”  (See  "Interpreting  CMMI  When  Using  Agile  Approaches”  in  Part  I.) 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more  information 
about  eliciting,  analyzing,  and  establishing  customer,  product,  and  product 
component  requirements. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
selecting,  designing,  and  implementing  solutions  to  requirements. 

Refer  to  the  Configuration  Management  process  area  for  more  information 
about  establishing  baselines  and  tracking  and  controlling  changes. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  the  project  against  the  plan  and  managing 
corrective  action  to  closure. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  and  maintaining  plans  that  define  project  activities. 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  analyzing  risks. 

Specific  Goal  and  Practice  Summary 

SG  1  Manage  Requirements 

SP1.1  Understand  Requirements 

SP  1 .2  Obtain  Commitment  to  Requirements 

SP1.3  Manage  Requirements  Changes 

SP  1 .4  Maintain  Bidirectional  Traceability  of  Requirements 

SP  1 .5  Ensure  Alignment  Between  Project  Work  and  Requirements 
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Specific  Practices  by  Goai 


SG  1  Manage  Requirements 

Requirements  are  managed  and  inconsistencies  with  project  pians  and  work 
products  are  identified. 

The  project  maintains  a  current  and  approved  set  of  requirements  over  the 
life  of  the  project  by  doing  the  following: 

•  Managing  all  changes  to  requirements 

•  Maintaining  relationships  among  requirements,  project  plans,  and  work 
products 

•  Ensuring  alignment  among  requirements,  project  plans,  and  work 
products 

•  Taking  corrective  action 

Refer  to  the  Requirements  Development  process  area  for  more  information 
about  analyzing  and  validating  requirements. 

Refer  to  the  Develop  Alternative  Solutions  and  Selection  Criteria  specific 
practice  in  the  Technical  Solution  process  area  for  more  information  about 
determining  the  feasibility  of  the  requirements. 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  managing  corrective  action  to  closure. 

SP1.1  Understand  Requirements 

Develop  an  understanding  with  the  requirements  providers  on  the 
meaning  of  the  requirements. 

As  the  project  matures  and  requirements  are  derived,  all  activities  or 
disciplines  will  receive  requirements.  To  avoid  requirements  creep,  criteria 
are  established  to  designate  appropriate  channels  or  official  sources  from 
which  to  receive  requirements.  Those  who  receive  requirements  conduct 
analyses  of  them  with  the  provider  to  ensure  that  a  compatible,  shared 
understanding  is  reached  on  the  meaning  of  requirements.  The  result  of 
these  analyses  and  dialogs  is  a  set  of  approved  requirements. 

Example  Work  Products 

1 .  Lists  of  criteria  for  distinguishing  appropriate  requirements  providers 

2.  Criteria  for  evaluation  and  acceptance  of  requirements 

3.  Results  of  analyses  against  criteria 

4.  A  set  of  approved  requirements 
Subpractices 

1 .  Establish  criteria  for  distinguishing  appropriate  requirements  providers. 

2.  Establish  objective  criteria  for  the  evaluation  and  acceptance  of 
requirements. 

Lack  of  evaluation  and  acceptance  criteria  often  results  in  inadequate  verification, 
costly  rework,  or  customer  rejection. 
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Examples  of  evaluation  and  acceptance  criteria  include  the  following: 

•  Clearly  and  properly  stated 

•  Complete 

•  Consistent  with  one  another 

•  Uniquely  identified 

•  Consistent  with  architectural  approach  and  quality  attribute  priorities 

•  Appropriate  to  implement 

•  Verifiable  (i.e.,  testable) 

•  Traceable 

•  Achievable 

•  Tied  to  business  value 

•  Identified  as  a  priority  for  the  customer 


3.  Analyze  requirements  to  ensure  that  established  criteria  are  met. 

4.  Reach  an  understanding  of  requirements  with  requirements  providers 
so  that  project  participants  can  commit  to  them. 

SP  1.2  Obtain  Commitment  to  Requirements 

Obtain  commitment  to  requirements  from  project  participants. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  monitoring  commitments. 

The  previous  specific  practice  dealt  with  reaching  an  understanding  with 
requirements  providers.  This  specific  practice  deals  with  agreements  and 
commitments  among  those  who  carry  out  activities  necessary  to  implement 
requirements.  Requirements  evolve  throughout  the  project.  As 
requirements  evolve,  this  specific  practice  ensures  that  project  participants 
commit  to  the  current  and  approved  requirements  and  the  resulting 
changes  in  project  plans,  activities,  and  work  products. 

Example  Work  Products 

1 .  Requirements  impact  assessments 

2.  Documented  commitments  to  requirements  and  requirements  changes 

Subpractices 

1 .  Assess  the  impact  of  requirements  on  existing  commitments. 

The  impact  on  the  project  participants  should  be  evaluated  when  the  requirements 
change  or  at  the  start  of  a  new  requirement. 

2.  Negotiate  and  record  commitments. 

Changes  to  existing  commitments  should  be  negotiated  before  project  participants 
commit  to  a  new  requirement  or  requirement  change. 
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SP  1.3  Manage  Requirements  Changes 

Manage  changes  to  requirements  as  they  evolve  during  the  project. 

Refer  to  the  Configuration  Management  process  area  for  more  information 
about  tracking  and  controiiing  changes. 

Requirements  change  for  a  variety  of  reasons.  As  needs  change  and  as 
work  proceeds,  changes  may  have  to  be  made  to  existing  requirements.  It 
is  essential  to  manage  these  additions  and  changes  efficiently  and 
effectively.  To  effectively  analyze  the  impact  of  changes,  it  is  necessary  that 
the  source  of  each  requirement  is  known  and  the  rationale  for  the  change  is 
documented.  The  project  may  want  to  track  appropriate  measures  of 
requirements  volatility  to  judge  whether  new  or  revised  approach  to  change 
control  is  necessary. 

Example  Work  Products 

1 .  Requirements  change  requests 

2.  Requirements  change  impact  reports 

3.  Requirements  status 

4.  Requirements  database 
Subpractices 

1 .  Document  all  requirements  and  requirements  changes  that  are  given  to 
or  generated  by  the  project. 

2.  Maintain  a  requirements  change  history,  including  the  rationale  for 
changes. 

Maintaining  the  change  history  heips  to  track  requirements  voiatiiity. 

3.  Evaluate  the  impact  of  requirement  changes  from  the  standpoint  of 
relevant  stakeholders. 

Requirements  changes  that  affect  the  product  architecture  can  affect  many 
stakehoiders. 

4.  Make  requirements  and  change  data  available  to  the  project. 

SP  1.4  Maintain  Bidirectional  Traceability  of  Requirements 

Maintain  bidirectional  traceability  among  requirements  and  work 
products. 

The  intent  of  this  specific  practice  is  to  maintain  the  bidirectional  traceability 
of  requirements.  (See  the  definition  of  “bidirectional  traceability”  in  the 
glossary.)  When  requirements  are  managed  well,  traceability  can  be 
established  from  a  source  requirement  to  its  lower  level  requirements  and 
from  those  lower  level  requirements  back  to  their  source  requirements. 

Such  bidirectional  traceability  helps  to  determine  whether  all  source 
requirements  have  been  completely  addressed  and  whether  all  lower  level 
requirements  can  be  traced  to  a  valid  source. 
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Requirements  traceability  also  covers  relationships  to  other  entities  such  as 
intermediate  and  final  work  products,  changes  in  design  documentation, 
and  test  plans.  Traceability  can  cover  horizontal  relationships,  such  as 
across  interfaces,  as  well  as  vertical  relationships.  Traceability  is 
particularly  needed  when  assessing  the  impact  of  requirements  changes  on 
project  activities  and  work  products. 

Examples  of  what  aspects  of  traceability  to  consider  include  the  following: 

•  Scope  of  traceability:  The  boundaries  within  which  traceability  is  needed 

•  Definition  of  traceability:  The  elements  that  need  logical  relationships 

•  Type  of  traceability:  When  horizontal  and  vertical  traceability  is  needed 


Such  bidirectional  traceability  is  not  always  automated.  It  can  be  done 
manually  using  spreadsheets,  databases,  and  other  common  tools. 

Example  Work  Products 

1 .  Requirements  traceability  matrix 

2.  Requirements  tracking  system 

Subpractices 

1 .  Maintain  requirements  traceability  to  ensure  that  the  source  of  lower 
level  (i.e.,  derived)  requirements  is  documented. 

2.  Maintain  requirements  traceability  from  a  requirement  to  its  derived 
requirements  and  allocation  to  work  products. 

Work  products  for  which  traceability  may  be  maintained  include  the  architecture, 
product  components,  development  iterations  (or  increments),  functions,  interfaces, 
objects,  people,  processes,  and  other  work  products. 

3.  Generate  a  requirements  traceability  matrix. 

SP  1.5  Ensure  Alignment  Between  Project  Work  and  Requirements 

Ensure  that  project  plans  and  work  products  remain  aligned  with 
requirements. 

This  specific  practice  finds  inconsistencies  between  requirements  and 
project  plans  and  work  products  and  initiates  corrective  actions  to  resolve 
them. 

Example  Work  Products 

1 .  Documentation  of  inconsistencies  between  requirements  and  project 
plans  and  work  products,  including  sources  and  conditions 

2.  Corrective  actions 
Subpractices 

1 .  Review  project  plans,  activities,  and  work  products  for  consistency  with 
requirements  and  changes  made  to  them. 

2.  Identify  the  source  of  the  inconsistency  (if  any). 
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3.  Identify  any  changes  that  should  be  made  to  plans  and  work  products 
resulting  from  changes  to  the  requirements  baseline. 

4.  Initiate  any  necessary  corrective  actions. 


Requirements  Management  (REQM) 


347 


CMMI  for  Development,  Version  1.3 


348 


Requirements  Management  (REQM) 


CMMI  for  Development,  Version  1.3 


RISK  MANAGEMENT 


A  Project  Management  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Risk  Management  (RSKM)  is  to  identify  potential  problems 
before  they  occur  so  that  risk  handling  activities  can  be  planned  and 
invoked  as  needed  across  the  life  of  the  product  or  project  to  mitigate 
adverse  impacts  on  achieving  objectives. 


Introductory  Notes 


Risk  management  is  a  continuous,  forward-looking  process  that  is  an 
important  part  of  project  management.  Risk  management  should  address 
issues  that  could  endanger  achievement  of  critical  objectives.  A  continuous 
risk  management  approach  effectively  anticipates  and  mitigates  risks  that 
can  have  a  critical  impact  on  a  project. 

Effective  risk  management  includes  early  and  aggressive  risk  identification 
through  collaboration  and  the  involvement  of  relevant  stakeholders  as 
described  in  the  stakeholder  involvement  plan  addressed  in  the  Project 
Planning  process  area.  Strong  leadership  among  all  relevant  stakeholders 
is  needed  to  establish  an  environment  for  free  and  open  disclosure  and 
discussion  of  risk. 

Risk  management  should  consider  both  internal  and  external,  as  well  as 
both  technical  and  non-technical,  sources  of  cost,  schedule,  performance, 
and  other  risks.  Early  and  aggressive  detection  of  risk  is  important  because 
it  is  typically  easier,  less  costly,  and  less  disruptive  to  make  changes  and 
correct  work  efforts  during  the  earlier,  rather  than  the  later,  phases  of  the 
project. 

For  example,  decisions  related  to  product  architecture  are  often  made  early 
before  their  impacts  can  be  fully  understood,  and  thus  the  risk  implications 
of  such  choices  should  be  carefully  considered. 

Industry  standards  can  help  when  determining  how  to  prevent  or  mitigate 
specific  risks  commonly  found  in  a  particular  industry.  Certain  risks  can  be 
proactively  managed  or  mitigated  by  reviewing  industry  best  practices  and 
lessons  learned. 

Risk  management  can  be  divided  into  the  following  parts: 

•  Defining  a  risk  management  strategy 

•  Identifying  and  analyzing  risks 

•  Handling  identified  risks,  including  the  implementation  of  risk  mitigation 
plans  as  needed 

As  represented  in  the  Project  Planning  and  Project  Monitoring  and  Control 
process  areas,  organizations  initially  may  focus  on  risk  identification  for 
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awareness  and  react  to  the  realization  of  these  risks  as  they  occur.  The 
Risk  Management  process  area  describes  an  evolution  of  these  specific 
practices  to  systematically  plan,  anticipate,  and  mitigate  risks  to  proactively 
minimize  their  impact  on  the  project. 

Although  the  primary  emphasis  of  the  Risk  Management  process  area  is  on 
the  project,  these  concepts  can  also  be  applied  to  manage  organizational 
risks. 

In  Agile  environments,  some  risk  management  activities  are  inherently  embedded  in  the 
Agile  method  used.  For  example,  some  technical  risks  can  be  addressed  by  encouraging 
experimentation  (early  "failures”)  or  by  executing  a  "spike”  outside  of  the  routine  iteration. 
However,  the  Risk  Management  process  area  encourages  a  more  systematic  approach  to 
managing  risks,  both  technical  and  non-technical.  Such  an  approach  can  be  integrated  into 
Agile’s  typical  iteration  and  meeting  rhythms;  more  specifically,  during  iteration  planning, 
task  estimating,  and  acceptance  of  tasks.  (See  "Interpreting  CMMI  When  Using  Agile 
Approaches”  in  Part  I.) 


Related  Process  Areas 


Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai  evaiuation 
process  that  evaiuates  identified  aiternatives  against  estabiished  criteria. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  monitoring  project  risks. 

Refer  to  the  Project  Pianning  process  area  for  more  information  about 
identifying  project  risks  and  pianning  stakehoider  invoivement. 

Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Risk  Management 

SP  1 .1  Determine  Risk  Sources  and  Categories 
SP  1 .2  Define  Risk  Parameters 
SP  1 .3  Establish  a  Risk  Management  Strategy 
SG  2  Identify  and  Analyze  Risks 
SP  2.1  Identify  Risks 

SP  2.2  Evaluate,  Categorize,  and  Prioritize  Risks 
SG  3  Mitigate  Risks 

SP  3.1  Develop  Risk  Mitigation  Plans 
SP  3.2  Implement  Risk  Mitigation  Plans 

Specific  Practices  by  Goal 


SG  1  Prepare  for  Risk  Management 

Preparation  for  risk  management  is  conducted. 

Prepare  for  risk  management  by  establishing  and  maintaining  a  strategy  for 
identifying,  analyzing,  and  mitigating  risks.  Typically,  this  strategy  is 
documented  in  a  risk  management  plan.  The  risk  management  strategy 
addresses  specific  actions  and  the  management  approach  used  to  apply 


350 


Risk  Management  (RSKM) 


CMMI  for  Development,  Version  1.3 


and  control  the  risk  management  program.  The  strategy  typically  includes 
identifying  sources  of  risk,  the  scheme  used  to  categorize  risks,  and 
parameters  used  to  evaluate,  bound,  and  control  risks  for  effective 
handling. 

SP  1 .1  Determine  Risk  Sources  and  Categories 

Determine  risk  sources  and  categories. 

Identifying  risk  sources  provides  a  basis  for  systematically  examining 
changing  situations  over  time  to  uncover  circumstances  that  affect  the 
ability  of  the  project  to  meet  its  objectives.  Risk  sources  are  both  internal 
and  external  to  the  project.  As  the  project  progresses,  additional  sources  of 
risk  can  be  identified.  Establishing  categories  for  risks  provides  a 
mechanism  for  collecting  and  organizing  risks  as  well  as  ensuring 
appropriate  scrutiny  and  management  attention  to  risks  that  can  have 
serious  consequences  on  meeting  project  objectives. 

Example  Work  Products 

1 .  Risk  source  lists  (external  and  internal) 

2.  Risk  categories  list 
Subpractices 

1 .  Determine  risk  sources. 

Risk  sources  are  fundamental  drivers  that  cause  risks  in  a  project  or  organization. 
There  are  many  sources  of  risks,  both  internal  and  external  to  a  project.  Risk  sources 
identify  where  risks  can  originate. 

;  Typical  internal  and  external  risk  sources  include  the  following: 

;  •  Uncertain  requirements 
I  •  Unprecedented  efforts  (i.e.,  estimates  unavailable) 

I  •  Infeasible  design 

I  •  Competing  quality  attribute  requirements  that  affect  solution  selection  and  design 

I  •  Unavailable  technology 

:  •  Unrealistic  schedule  estimates  or  allocation 

:  •  Inadequate  staffing  and  skills 

:  •  Cost  or  funding  issues 

i  •  Uncertain  or  inadequate  subcontractor  capability 

i  •  Uncertain  or  inadequate  supplier  capability 

i  •  Inadequate  communication  with  actual  or  potential  customers  or  with  their 
;  representatives 

i  •  Disruptions  to  the  continuity  of  operations 
;  •  Regulatory  constraints  (e.g.  security,  safety,  environment) 


Many  of  these  sources  of  risk  are  accepted  without  adequately  planning  for  them. 
Early  identification  of  both  internal  and  external  sources  of  risk  can  lead  to  early 
identification  of  risks.  Risk  mitigation  plans  can  then  be  implemented  early  in  the 
project  to  preclude  occurrence  of  risks  or  reduce  consequences  of  their  occurrence. 
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2.  Determine  risk  categories. 

Risk  categories  are  "bins”  used  for  collecting  and  organizing  risks.  Identifying  risk 
categories  aids  the  future  consolidation  of  activities  in  risk  mitigation  plans. 

;  The  following  factors  can  be  considered  when  determining  risk  categories: 

;  •  Phases  of  the  project's  lifecycle  model  (e.g.,  requirements,  design,  manufacturing,  test 
I  and  evaluation,  delivery,  disposal) 

I  •  Types  of  processes  used 

•  Typesof  products  used 

I  •  Project  management  risks  (e.g.,  contract  risks,  budget  risks,  schedule  risks,  resource 
I  risks) 

•  Technical  performance  risks  (e.g.,  quality  attribute  related  risks,  supportability  risks) 


A  risk  taxonomy  can  be  used  to  provide  a  framework  for  determining  risk  sources  and 
categories. 

SP  1.2  Define  Risk  Parameters 

Define  parameters  used  to  analyze  and  categorize  risks  and  to 
control  the  risk  management  effort 

Parameters  for  evaluating,  categorizing,  and  prioritizing  risks  include  the 
following: 

•  Risk  likelihood  (i.e.,  probability  of  risk  occurrence) 

•  Risk  consequence  (i.e.,  impact  and  severity  of  risk  occurrence) 

•  Thresholds  to  trigger  management  activities 

Risk  parameters  are  used  to  provide  common  and  consistent  criteria  for 
comparing  risks  to  be  managed.  Without  these  parameters,  it  is  difficult  to 
gauge  the  severity  of  an  unwanted  change  caused  by  a  risk  and  to  prioritize 
the  actions  required  for  risk  mitigation  planning. 

Projects  should  document  the  parameters  used  to  analyze  and  categorize 
risks  so  that  they  are  available  for  reference  throughout  the  life  of  the 
project  because  circumstances  change  over  time.  Using  these  parameters, 
risks  can  easily  be  re-categorized  and  analyzed  when  changes  occur. 

The  project  can  use  techniques  such  as  failure  mode  and  effects  analysis 
(FMEA)  to  examine  risks  of  potential  failures  in  the  product  or  in  selected 
product  development  processes.  Such  techniques  can  help  to  provide 
discipline  in  working  with  risk  parameters. 

Example  Work  Products 

1 .  Risk  evaluation,  categorization,  and  prioritization  criteria 

2.  Risk  management  requirements  (e.g.,  control  and  approval  levels, 
reassessment  intervals) 

Subpractices 

1 .  Define  consistent  criteria  for  evaluating  and  quantifying  risk  likelihood 
and  severity  levels. 
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Consistently  used  criteria  (e.g.,  bounds  on  likelihood,  severity  levels)  allow  impacts  of 
different  risks  to  be  commonly  understood,  to  receive  the  appropriate  level  of  scrutiny, 
and  to  obtain  the  management  attention  warranted.  In  managing  dissimilar  risks  (e.g., 
staff  safety  versus  environmental  pollution),  it  is  important  to  ensure  consistency  in  the 
end  result.  (For  example,  a  high-impact  risk  of  environmental  pollution  is  as  important 
as  a  high-impact  risk  to  staff  safety.)  One  way  of  providing  a  common  basis  for 
comparing  dissimilar  risks  is  assigning  dollar  values  to  risks  (e.g.,  through  a  process  of 
risk  monetization). 

2.  Define  thresholds  for  each  risk  category. 

For  each  risk  category,  thresholds  can  be  established  to  determine  acceptability  or 
unacceptability  of  risks,  prioritization  of  risks,  or  triggers  for  management  action. 

I  Examples  of  thresholds  include  the  following: 

I  •  Project-wide  thresholds  could  be  established  to  involve  senior  management  when 
:  product  costs  exceed  1 0  percent  of  the  target  cost  or  when  cost  performance  indices 

I  (CPIs)  fall  below  0.95. 

i  •  Schedule  thresholds  could  be  established  to  involve  senior  management  when 
;  schedule  performance  indices  (SPIs)  fall  below  0.95. 

i  •  Performance  thresholds  could  be  established  to  involve  senior  management  when 
;  specified  key  items  (e.g.,  processor  utilization,  average  response  times)  exceed  125 
;  percent  of  the  intended  design. 


3.  Define  bounds  on  the  extent  to  which  thresholds  are  applied  against  or 
within  a  category. 

There  are  few  limits  to  which  risks  can  be  assessed  in  either  a  quantitative  or 
qualitative  fashion.  Definition  of  bounds  (or  boundary  conditions)  can  be  used  to  help 
define  the  extent  of  the  risk  management  effort  and  avoid  excessive  resource 
expenditures.  Bounds  can  include  the  exclusion  of  a  risk  source  from  a  category. 
These  bounds  can  also  exclude  conditions  that  occur  below  a  given  frequency. 

SP  1 .3  Establish  a  Risk  Management  Strategy 

Establish  and  maintain  the  strategy  to  be  used  for  risk 

management. 

A  comprehensive  risk  management  strategy  addresses  items  such  as  the 

following: 

•  The  scope  of  the  risk  management  effort 

•  Methods  and  tools  to  be  used  for  risk  identification,  risk  analysis,  risk 
mitigation,  risk  monitoring,  and  communication 

•  Project  specific  sources  of  risks 

•  How  risks  are  to  be  organized,  categorized,  compared,  and 
consolidated 

•  Parameters  used  for  taking  action  on  identified  risks,  including 
likelihood,  consequence,  and  thresholds 

•  Risk  mitigation  techniques  to  be  used,  such  as  prototyping,  piloting, 
simulation,  alternative  designs,  or  evolutionary  development 

•  The  definition  of  risk  measures  used  to  monitor  the  status  of  risks 
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•  Time  intervals  for  risk  monitoring  or  reassessment 

The  risk  management  strategy  should  be  guided  by  a  common  vision  of 
success  that  describes  desired  future  project  outcomes  in  terms  of  the 
product  delivered,  its  cost,  and  its  fitness  for  the  task.  The  risk  management 
strategy  is  often  documented  in  a  risk  management  plan  for  the 
organization  or  project.  This  strategy  is  reviewed  with  relevant  stakeholders 
to  promote  commitment  and  understanding. 

A  risk  management  strategy  should  be  developed  early  in  the  project,  so 
that  relevant  risks  are  identified  and  managed  proactively.  Early 
identification  and  assessment  of  critical  risks  allows  the  project  to  formulate 
risk  handling  approaches  and  adjust  project  definition  and  allocation  of 
resources  based  on  critical  risks. 

Example  Work  Products 

1 .  Project  risk  management  strategy 

SG  2  Identify  and  Analyze  Risks 

Risks  are  identified  and  anaiyzed  to  determine  their  reiative  importance. 

The  degree  of  risk  affects  the  resources  assigned  to  handle  the  risk  and  the 
timing  of  when  appropriate  management  attention  is  required. 

Risk  analysis  entails  identifying  risks  from  identified  internal  and  external 
sources  and  evaluating  each  identified  risk  to  determine  its  likelihood  and 
consequences.  Risk  categorization,  based  on  an  evaluation  against 
established  risk  categories  and  criteria  developed  for  the  risk  management 
strategy,  provides  information  needed  for  risk  handling.  Related  risks  can 
be  grouped  to  enable  efficient  handling  and  effective  use  of  risk 
management  resources. 

SP  2.1  Identify  Risks 

identify  and  document  risks. 

Identifying  potential  issues,  hazards,  threats,  and  vulnerabilities  that  could 
negatively  affect  work  efforts  or  plans  is  the  basis  for  sound  and  successful 
risk  management.  Risks  should  be  identified  and  described  understandably 
before  they  can  be  analyzed  and  managed  properly.  Risks  are  documented 
in  a  concise  statement  that  includes  the  context,  conditions,  and 
consequences  of  risk  occurrence. 

Risk  identification  should  be  an  organized,  thorough  approach  to  seek  out 
probable  or  realistic  risks  in  achieving  objectives.  To  be  effective,  risk 
identification  should  not  attempt  to  address  every  possible  event.  Using 
categories  and  parameters  developed  in  the  risk  management  strategy  and 
identified  sources  of  risk  can  provide  the  discipline  and  streamlining 
appropriate  for  risk  identification.  Identified  risks  form  a  baseline  for 
initiating  risk  management  activities.  Risks  should  be  reviewed  periodically 
to  reexamine  possible  sources  of  risk  and  changing  conditions  to  uncover 
sources  and  risks  previously  overlooked  or  nonexistent  when  the  risk 
management  strategy  was  last  updated. 
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Risk  identification  focuses  on  the  identification  of  risks,  not  the  placement  of 
blame.  The  results  of  risk  identification  activities  should  never  be  used  by 
management  to  evaluate  the  performance  of  individuals. 

Many  methods  are  used  for  identifying  risks.  Typical  identification  methods  include  the 
following: 

•  Examine  each  element  of  the  project  work  breakdown  structure. 

•  Conduct  a  risk  assessment  using  a  risk  taxonomy. 

•  Interview  subject  matter  experts. 

•  Review  risk  management  efforts  from  similar  products. 

•  Examine  lessons  learned  documents  or  databases. 

•  Examine  design  specifications  and  agreement  requirements. 


Example  Work  Products 

1 .  List  of  identified  risks,  including  the  context,  conditions,  and 
consequences  of  risk  occurrence 

Subpractices 

1 .  Identify  the  risks  associated  with  cost,  schedule,  and  performance. 

Risks  associated  with  cost,  schedule,  performance,  and  other  business  objectives 
should  be  examined  to  understand  their  effect  on  project  objectives.  Risk  candidates 
can  be  discovered  that  are  outside  the  scope  of  project  objectives  but  vital  to  customer 
interests.  For  example,  risks  in  development  costs,  product  acquisition  costs,  cost  of 
spare  (or  replacement)  products,  and  product  disposition  (or  disposal)  costs  have 
design  implications. 

The  customer  may  not  have  considered  the  full  cost  of  supporting  a  fielded  product  or 
using  a  delivered  service.  The  customer  should  be  informed  of  such  risks,  but  actively 
managing  those  risks  may  not  be  necessary.  Mechanisms  for  making  such  decisions 
should  be  examined  at  project  and  organization  levels  and  put  in  place  if  deemed 
appropriate,  especially  for  risks  that  affect  the  project’s  ability  to  verify  and  validate  the 
product. 

In  addition  to  the  cost  risks  identified  above,  other  cost  risks  can  include  the  ones 
associated  with  funding  levels,  funding  estimates,  and  distributed  budgets. 

Schedule  risks  can  include  risks  associated  with  planned  activities,  key  events,  and 
milestones. 


Risk  Management  (RSKM) 


355 


CMMI  for  Development,  Version  1.3 


Performance  risks  can  include  risks  associated  with  the  following: 

•  Requirements 

•  Analysis  and  design 

•  Application  of  new  technology 

•  Physical  size 

•  Shape 

•  Weight 

•  Manufacturing  and  fabrication 

•  Product  behavior  and  operation  with  respect  to  functionality  or  quality  attributes 

•  Verification 

•  Validation 

•  Performance  maintenance  attributes 


Performance  maintenance  attributes  are  those  characteristics  that  enable  an  in-use 
product  or  service  to  provide  required  performance,  such  as  maintaining  safety  and 
security  performance. 

There  are  risks  that  do  not  fall  into  cost,  schedule,  or  performance  categories,  but  can 
be  associated  with  other  aspects  of  the  organization’s  operation. 

Examples  of  these  other  risks  include  risks  related  to  the  following: 

•  Strikes 

•  Diminishing  sources  of  supply 

•  Technology  cycle  time 

•  Competition 


2.  Review  environmental  elements  that  can  affect  the  project. 

Risks  to  a  project  that  frequently  are  missed  include  risks  supposedly  outside  the 
scope  of  the  project  (i.e.,  the  project  does  not  control  whether  they  occur  but  can 
mitigate  their  impact).  These  risks  can  include  weather  or  natural  disasters,  political 
changes,  and  telecommunications  failures. 

3.  Review  all  elements  of  the  work  breakdown  structure  as  part  of 
identifying  risks  to  help  ensure  that  all  aspects  of  the  work  effort  have 
been  considered. 

4.  Review  all  elements  of  the  project  plan  as  part  of  identifying  risks  to 
help  ensure  that  all  aspects  of  the  project  have  been  considered. 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  project  risks. 

5.  Document  the  context,  conditions,  and  potential  consequences  of  each 
risk. 

Risk  statements  are  typically  documented  in  a  standard  format  that  contains  the  risk 
context,  conditions,  and  consequences  of  occurrence.  The  risk  context  provides 
additional  information  about  the  risk  such  as  the  relative  time  frame  of  the  risk,  the 


356 


Risk  Management  (RSKM) 


CMMI  for  Development,  Version  1.3 


circumstances  or  conditions  surrounding  the  risk  that  has  brought  about  the  concern, 
and  any  doubt  or  uncertainty. 

6.  Identify  the  relevant  stakeholders  associated  with  each  risk. 

SP  2.2  Evaluate,  Categorize,  and  Prioritize  Risks 

Evaluate  and  categorize  each  identified  risk  using  defined  risk 
categories  and  parameters,  and  determine  its  relative  priority. 

The  evaluation  of  risks  is  needed  to  assign  a  relative  importance  to  each 
identified  risk  and  is  used  in  determining  when  appropriate  management 
attention  is  required.  Often  it  is  useful  to  aggregate  risks  based  on  their 
interrelationships  and  develop  options  at  an  aggregate  level.  When  an 
aggregate  risk  is  formed  by  a  roll  up  of  lower  level  risks,  care  should  be 
taken  to  ensure  that  important  lower  level  risks  are  not  ignored. 

Collectively,  the  activities  of  risk  evaluation,  categorization,  and  prioritization 
are  sometimes  called  a  “risk  assessment”  or  “risk  analysis.” 

Example  Work  Products 

1 .  List  of  risks  and  their  assigned  priority 

Subpractices 

1 .  Evaluate  identified  risks  using  defined  risk  parameters. 

Each  risk  is  evaiuated  and  assigned  vaiues  according  to  defined  risk  parameters, 
which  can  inciude  iikeiihood,  consequence  (i.e.,  severity,  impact),  and  threshoids.  The 
assigned  risk  parameter  vaiues  can  be  integrated  to  produce  additionai  measures, 
such  as  risk  exposure  (i.e.,  the  combination  of  iikeiihood  and  consequence),  which  can 
be  used  to  prioritize  risks  for  handiing. 

Often,  a  scaie  with  three  to  five  vaiues  is  used  to  evaiuate  both  iikeiihood  and 
consequence. 

;  Iikeiihood,  for  exampie,  can  be  categorized  as  remote,  uniikeiy,  iikeiy,  highiy  iikeiy,  or 
I  neariy  certain. 


Exampie  categories  for  consequence  inciude  the  foiiowing: 

•  Low 

•  Medium 
.  High 

•  Negligible 

•  Marginal 

•  Significant 

•  Critical 

•  Catastrophic 


Probability  values  are  frequently  used  to  quantify  likelihood.  Consequences  are 
generally  related  to  cost,  schedule,  environmental  impact,  or  human  measures  (e.g., 
labor  hours  lost,  severity  of  injury). 
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Risk  evaluation  is  often  a  difficult  and  time  consuming  task.  Specific  expertise  or  group 
techniques  may  be  needed  to  assess  risks  and  gain  confidence  in  the  prioritization.  In 
addition,  priorities  can  require  reevaluation  as  time  progresses.  To  provide  a  basis  for 
comparing  the  impact  of  the  realization  of  identified  risks,  consequences  of  the  risks 
can  be  monetized. 

2.  Categorize  and  group  risks  according  to  defined  risk  categories. 

Risks  are  categorized  into  defined  risk  categories,  providing  a  means  to  review  them 
according  to  their  source,  taxonomy,  or  project  component.  Related  or  equivalent  risks 
can  be  grouped  for  efficient  handling.  The  cause-and-effect  relationships  between 
related  risks  are  documented. 

3.  Prioritize  risks  for  mitigation. 

A  relative  priority  is  determined  for  each  risk  based  on  assigned  risk  parameters.  Clear 
criteria  should  be  used  to  determine  risk  priority.  Risk  prioritization  helps  to  determine 
the  most  effective  areas  to  which  resources  for  risks  mitigation  can  be  applied  with  the 
greatest  positive  impact  on  the  project. 

SG  3 _ Mitigate  Risks _ 

Risks  are  handled  and  mitigated  as  appropriate  to  reduce  adverse  impacts  on 
achieving  objectives. 

The  steps  in  handling  risks  include  developing  risk  handling  options, 
monitoring  risks,  and  performing  risk  handling  activities  when  defined 
thresholds  are  exceeded.  Risk  mitigation  plans  are  developed  and 
implemented  for  selected  risks  to  proactively  reduce  the  potential  impact  of 
risk  occurrence.  Risk  mitigation  planning  can  also  include  contingency 
plans  to  deal  with  the  impact  of  selected  risks  that  can  occur  despite 
attempts  to  mitigate  them.  Risk  parameters  used  to  trigger  risk  handling 
activities  are  defined  by  the  risk  management  strategy. 

SP  3.1  Develop  Risk  Mitigation  Plans 

Develop  a  risk  mitigation  plan  in  accordance  with  the  risk 
management  strategy. 

A  critical  component  of  risk  mitigation  planning  is  developing  alternative 
courses  of  action,  workarounds,  and  fallback  positions,  and  a 
recommended  course  of  action  for  each  critical  risk.  The  risk  mitigation  plan 
for  a  given  risk  includes  techniques  and  methods  used  to  avoid,  reduce, 
and  control  the  probability  of  risk  occurrence;  the  extent  of  damage  incurred 
should  the  risk  occur  (sometimes  called  a  “contingency  plan”);  or  both. 

Risks  are  monitored  and  when  they  exceed  established  thresholds,  risk 
mitigation  plans  are  deployed  to  return  the  affected  effort  to  an  acceptable 
risk  level.  If  the  risk  cannot  be  mitigated,  a  contingency  plan  can  be 
invoked.  Both  risk  mitigation  and  contingency  plans  often  are  generated 
only  for  selected  risks  for  which  consequences  of  the  risks  are  high  or 
unacceptable.  Other  risks  may  be  accepted  and  simply  monitored. 
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Options  for  handling  risks  typically  include  alternatives  such  as  the  following: 

•  Risk  avoidance:  changing  or  lowering  requirements  while  still  meeting  end  user  needs 

•  Risk  control:  taking  active  steps  to  minimize  risks 

•  Risk  transfer:  reallocating  requirements  to  lower  risks 

•  Risk  monitoring:  watching  and  periodically  reevaluating  the  risk  for  changes  in  assigned 
risk  parameters 

•  Risk  acceptance:  acknowledging  risk  but  not  taking  action 


Often,  especially  for  high-impact  risks,  more  than  one  approach  to  handling 
a  risk  should  be  generated. 

For  example,  in  the  case  of  an  event  that  disrupts  the  continuity  of  operations,  approaches 
to  risk  management  can  include  establishing  the  following: 

•  Resource  reserves  to  respond  to  disruptive  events 

•  Lists  of  available  backup  equipment 

•  Backups  to  key  staff 

•  Plans  for  testing  emergency  response  systems 

•  Posted  procedures  for  emergencies 

•  Disseminated  lists  of  key  contacts  and  information  resources  for  emergencies 


In  many  cases,  risks  are  accepted  or  watched.  Risk  acceptance  is  usually 
done  when  the  risk  is  judged  too  low  for  formal  mitigation  or  when  there 
appears  to  be  no  viable  way  to  reduce  the  risk.  If  a  risk  is  accepted,  the 
rationale  for  this  decision  should  be  documented.  Risks  are  watched  when 
there  is  an  objectively  defined,  verifiable,  and  documented  threshold  (e.g., 
for  cost,  schedule,  performance,  risk  exposure)  that  will  trigger  risk 
mitigation  planning  or  invoke  a  contingency  plan. 

Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  evaiuating  aiternatives  and  seiecting  soiutions. 

Adequate  consideration  should  be  given  early  to  technology 
demonstrations,  models,  simulations,  pilots,  and  prototypes  as  part  of  risk 
mitigation  planning. 

Example  Work  Products 

1 .  Documented  handling  options  for  each  identified  risk 

2.  Risk  mitigation  plans 

3.  Contingency  plans 

4.  List  of  those  who  are  responsible  for  tracking  and  addressing  each  risk 
Subpractices 

1 .  Determine  the  levels  and  thresholds  that  define  when  a  risk  becomes 
unacceptable  and  triggers  the  execution  of  a  risk  mitigation  plan  or 
contingency  plan. 
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Risk  level  (derived  using  a  risk  model)  is  a  measure  combining  the  uncertainty  of 
reaching  an  objective  with  the  consequences  of  failing  to  reach  the  objective. 

Risk  levels  and  thresholds  that  bound  planned  or  acceptable  cost,  schedule,  or 
performance  should  be  clearly  understood  and  defined  to  provide  a  means  with  which 
risk  can  be  understood.  Proper  categorization  of  risk  is  essential  for  ensuring  an 
appropriate  priority  based  on  severity  and  the  associated  management  response. 

There  can  be  multiple  thresholds  employed  to  initiate  varying  levels  of  management 
response.  Typically,  thresholds  for  the  execution  of  risk  mitigation  plans  are  set  to 
engage  before  the  execution  of  contingency  plans. 

2.  Identify  the  person  or  group  responsible  for  addressing  each  risk. 

3.  Determine  the  costs  and  benefits  of  implementing  the  risk  mitigation 
plan  for  each  risk. 

Risk  mitigation  activities  should  be  examined  for  benefits  they  provide  versus 
resources  they  will  expend.  Just  like  any  other  design  activity,  alternative  plans  may 
need  to  be  developed  and  costs  and  benefits  of  each  alternative  assessed.  The  most 
appropriate  plan  is  selected  for  implementation. 

4.  Develop  an  overall  risk  mitigation  plan  for  the  project  to  orchestrate  the 
implementation  of  individual  risk  mitigation  and  contingency  plans. 

The  complete  set  of  risk  mitigation  plans  may  not  be  affordable.  A  tradeoff  analysis 
should  be  performed  to  prioritize  risk  mitigation  plans  for  implementation. 

5.  Develop  contingency  plans  for  selected  critical  risks  in  the  event  their 
impacts  are  realized. 

Risk  mitigation  plans  are  developed  and  implemented  as  needed  to  proactively  reduce 
risks  before  they  become  problems.  Despite  best  efforts,  some  risks  can  be 
unavoidable  and  will  become  problems  that  affect  the  project.  Contingency  plans  can 
be  developed  for  critical  risks  to  describe  actions  a  project  can  take  to  deal  with  the 
occurrence  of  this  impact.  The  intent  is  to  define  a  proactive  plan  for  handling  the  risk. 
Either  the  risk  is  reduced  (mitigation)  or  addressed  (contingency).  In  either  event,  the 
risk  is  managed. 

Some  risk  management  literature  may  consider  contingency  plans  a  synonym  or 
subset  of  risk  mitigation  plans.  These  plans  also  can  be  addressed  together  as  risk 
handling  or  risk  action  plans. 

SP  3.2  Implement  Risk  Mitigation  Plans 

Monitor  the  status  of  each  risk  periodicaiiy  and  impiement  the  risk 
mitigation  pian  as  appropriate. 

To  effectively  control  and  manage  risks  during  the  work  effort,  follow  a 
proactive  program  to  regularly  monitor  risks  and  the  status  and  results  of 
risk  handling  actions.  The  risk  management  strategy  defines  the  intervals  at 
which  risk  status  should  be  revisited.  This  activity  can  result  in  the  discovery 
of  new  risks  or  new  risk  handling  options  that  can  require  replanning  and 
reassessment.  In  either  event,  acceptability  thresholds  associated  with  the 
risk  should  be  compared  to  the  risk  status  to  determine  the  need  for 
implementing  a  risk  mitigation  plan. 
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Example  Work  Products 

1 .  Updated  lists  of  risk  status 

2.  Updated  assessments  of  risk  likelihood,  consequence,  and  thresholds 

3.  Updated  list  of  risk  handling  options 

4.  Updated  list  of  actions  taken  to  handle  risks 

5.  Risk  mitigation  plans  of  risk  handling  options 

Subpractices 

1.  Monitor  risk  status. 

After  a  risk  mitigation  plan  is  initiated,  the  risk  is  still  monitored.  Thresholds  are 
assessed  to  check  for  the  potential  execution  of  a  contingency  plan. 

A  mechanism  for  monitoring  should  be  employed. 

2.  Provide  a  method  for  tracking  open  risk  handling  action  items  to 
closure. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  managing  corrective  action  to  ciosure. 

3.  Invoke  selected  risk  handling  options  when  monitored  risks  exceed 
defined  thresholds. 

Often,  risk  handling  is  only  performed  for  risks  judged  to  be  high  and  medium.  The  risk 
handling  strategy  for  a  given  risk  can  include  techniques  and  methods  to  avoid, 
reduce,  and  control  the  likelihood  of  the  risk  or  the  extent  of  damage  incurred  should 
the  risk  occur,  or  both.  In  this  context,  risk  handling  includes  both  risk  mitigation  plans 
and  contingency  plans. 

Risk  handling  techniques  are  developed  to  avoid,  reduce,  and  control  adverse  impact 
to  project  objectives  and  to  bring  about  acceptable  outcomes  in  light  of  probable 
impacts.  Actions  generated  to  handle  a  risk  require  proper  resource  loading  and 
scheduling  in  plans  and  baseline  schedules.  This  replanning  should  closely  consider 
the  effects  on  adjacent  or  dependent  work  initiatives  or  activities. 

4.  Establish  a  schedule  or  period  of  performance  for  each  risk  handling 
activity  that  includes  a  start  date  and  anticipated  completion  date. 

5.  Provide  a  continued  commitment  of  resources  for  each  plan  to  allow 
the  successful  execution  of  risk  handling  activities. 

6.  Collect  performance  measures  on  risk  handling  activities. 
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SUPPLIER  AGREEMENT  MANAGEMENT 

A  Project  Management  Process  Area  at  Maturity  Level  2 


Purpose 


The  purpose  of  Supplier  Agreement  Management  (SAM)  is  to  manage  the 
acquisition  of  products  and  services  from  suppliers. 


Introductory  Notes 


The  scope  of  this  process  area  addresses  the  acquisition  of  products, 
services,  and  product  and  service  components  that  can  be  delivered  to  the 
project’s  customer  or  included  in  a  product  or  service  system.  This  process 
area’s  practices  can  also  be  used  for  other  purposes  that  benefit  the  project 
(e.g.,  purchasing  consumables). 

This  process  area  does  not  apply  in  all  contexts  in  which  commercial  off- 
the-shelf  (COTS)  components  are  acquired  but  does  apply  in  cases  where 
there  are  modifications  to  COTS  components,  government  off-the-shelf 
components,  or  freeware,  that  are  of  significant  value  to  the  project  or  that 
represent  significant  project  risk. 

Throughout  the  process  areas,  where  the  terms  “product”  and  “product 
component”  are  used,  their  intended  meanings  also  encompass  services, 
service  systems,  and  their  components. 

The  Supplier  Agreement  Management  process  area  involves  the  following 
activities: 

•  Determining  the  type  of  acquisition 

•  Selecting  suppliers 

•  Establishing  and  maintaining  agreements  with  suppliers 

•  Executing  supplier  agreements 

•  Accepting  delivery  of  acquired  products 

•  Ensuring  successful  transition  of  acquired  products 

This  process  area  primarily  addresses  the  acquisition  of  products  and 
product  components  that  are  delivered  to  the  project’s  customer. 

Examples  of  products  and  product  components  that  can  be  acquired  by  the  project  include 
the  following: 

•  Subsystems  (e.g.,  navigational  system  on  an  airplane) 

•  Software 

•  Hardware 

•  Documentation  (e.g.,  installation,  operator’s,  and  user’s  manuals) 

•  Parts  and  materials  (e.g.,  gauges,  switches,  wheels,  steel,  raw  materials) 
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To  minimize  risks  to  the  project,  this  process  area  can  also  address  the 
acquisition  of  significant  products  and  product  components  not  delivered  to 
the  project’s  customer  but  used  to  develop  and  maintain  the  product  or 
service  (for  example,  development  tools  and  test  environments). 

Typically,  the  products  to  be  acquired  by  the  project  are  determined  during 
the  early  stages  of  planning  and  development. 

The  Technical  Solution  process  area  provides  practices  for  determining  the 
products  and  product  components  that  can  be  acquired  from  suppliers. 

This  process  area  does  not  directly  address  arrangements  in  which  the 
supplier  is  integrated  into  the  project  team  and  uses  the  same  processes 
and  reports  to  the  same  management  as  the  project  team  members  (e.g., 
integrated  teams).  Typically,  these  situations  are  handled  by  other 
processes  or  functions  (e.g.,  project  management  processes,  processes  or 
functions  external  to  the  project)  though  some  of  the  specific  practices  of 
this  process  area  can  be  useful  in  managing  the  supplier  agreement. 

This  process  area  typically  is  not  implemented  to  address  arrangements  in 
which  the  project’s  customer  is  also  a  supplier.  These  situations  are  usually 
handled  by  either  informal  agreements  with  the  customer  or  by  specification 
of  the  customer  furnished  items  in  the  overall  agreement  that  the  project 
has  with  the  customer.  In  the  latter  case,  some  of  the  specific  practices  of 
this  process  area  can  be  useful  in  managing  the  agreement,  although 
others  may  not,  due  to  the  fundamentally  different  relationship  that  exists 
with  a  customer  as  opposed  to  an  ordinary  supplier.  See  the  CMMI-ACQ 
model  for  more  information  about  other  types  of  agreements. 

Suppliers  can  take  many  forms  depending  on  business  needs,  including  in- 
house  suppliers  (i.e.,  suppliers  that  are  in  the  same  organization  but  are 
external  to  the  project),  fabrication  departments,  suppliers  of  reuse  libraries, 
and  commercial  suppliers.  (See  the  definition  of  “supplier”  in  the  glossary.) 

A  supplier  agreement  is  established  to  manage  the  relationship  between 
the  organization  and  the  supplier.  A  supplier  agreement  is  any  written 
agreement  between  the  organization  (representing  the  project)  and  the 
supplier.  This  agreement  can  be  a  contract,  license,  service  level 
agreement,  or  memorandum  of  agreement.  The  acquired  product  is 
delivered  to  the  project  from  the  supplier  according  to  the  supplier 
agreement.  (See  the  definition  of  “supplier  agreement”  in  the  glossary.) 


Related  Process  Areas 


Refer  to  the  Technical  Solution  process  area  for  more  information  about 
performing  make,  buy,  or  reuse  analysis. 

Refer  to  the  Requirements  Development  process  area  for  more  information 
about  eliciting,  analyzing,  and  establishing  customer,  product,  and  product 
component  requirements. 
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Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  monitoring  the  project  against  the  pian  and  managing 
corrective  action  to  ciosure. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  maintaining  bidirectionai  traceabiiity  of  requirements. 

Specific  Goai  and  Practice  Summary 

SG  1  Establish  Supplier  Agreements 

SP  1 .1  Determine  Acquisition  Type 

SP1.2  Seiect  Suppliers 

SP  1 .3  Estabiish  Suppiier  Agreements 

SG  2  Satisfy  Supplier  Agreements 

SP  2.1  Execute  the  Supplier  Agreement 
SP  2.2  Accept  the  Acquired  Product 

SP  2.3  Ensure  Transition  of  Products 

Specific  Practices  by  Goai 


SG  1 _ Establish  Supplier  Agreements _ 

Agreements  with  the  suppliers  are  established  and  maintained. 

SP  1.1  Determine  Acquisition  Type 

Determine  the  type  of  acquisition  for  each  product  or  product 
component  to  be  acquired. 

Refer  to  the  Technicai  Soiution  process  area  for  more  information  about 
performing  make,  buy,  or  reuse  anaiyses. 

Many  different  types  of  acquisitions  can  be  used  to  acquire  products  and 
product  components  that  can  be  used  by  the  project. 

:  Examples  of  types  of  acquisitions  include  the  following: 

i  •  Purchasing  modified  COTS  products  of  significant  value  to  the  project 
;  •  Obtaining  products  through  a  supplier  agreement 
i  •  Obtaining  products  from  an  in-house  supplier 
I  •  Obtaining  products  from  the  customer 
I  •  Obtaining  products  from  a  preferred  supplier 

;  •  Combining  some  of  the  above  (e.g.,  contracting  for  a  modification  to  a  COTS  product, 

;  having  another  part  of  the  business  enterprise  co-develop  products  with  an  external 
:  supplier) 


If  acquiring  modified  COTS  products  of  significant  value  to  the  project  or 
that  represent  significant  project  risk,  care  in  evaluating  and  selecting  these 
products  and  the  supplier  can  be  critical  to  the  project.  Aspects  to  consider 
in  the  selection  decision  include  proprietary  issues  and  the  availability  of  the 
products. 
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Example  Work  Products 

1 .  List  of  the  acquisition  types  that  will  be  used  for  all  products  and 
product  components  to  be  acquired 

SP  1.2  Select  Suppliers 

Select  suppliers  based  on  an  evaluation  of  their  ability  to  meet  the 
specified  requirements  and  established  criteria. 

Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai  evaiuation 
process  that  evaiuates  identified  aiternatives  against  estabiished  criteria. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  obtaining  commitment  to  requirements. 

Criteria  should  be  established  to  address  factors  that  are  important  to  the 
project. 

;  Examples  of  factors  that  can  be  important  to  the  project  include  the  following: 

i  •  Geographical  location  of  the  supplier 
;  •  Supplier’s  performance  records  on  similar  work 
i  •  Engineering  capabilities 
I  •  Staff  and  facilities  available  to  perform  the  work 
I  •  Prior  experience  in  similar  situations 

;  •  Customer  satisfaction  with  similar  products  delivered  by  the  supplier 


Example  Work  Products 

1 .  Market  studies 

2.  List  of  candidate  suppliers 

3.  Preferred  supplier  list 

4.  Trade  study  or  other  record  of  evaluation  criteria,  advantages  and 
disadvantages  of  candidate  suppliers,  and  rationale  for  selection  of 
suppliers 

5.  Solicitation  materials  and  requirements 
Subpractices 

1 .  Establish  and  document  criteria  for  evaluating  potential  suppliers. 

2.  Identify  potential  suppliers  and  distribute  solicitation  material  and 
requirements  to  them. 

A  proactive  manner  of  performing  this  activity  is  to  conduct  market  research  to  identify 
potential  sources  of  candidate  products  to  be  acquired,  including  candidates  from 
suppliers  of  custom  made  products  and  suppliers  of  COTS  products. 

3.  Evaluate  proposals  according  to  evaluation  criteria. 

4.  Evaluate  risks  associated  with  each  proposed  supplier. 
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Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  anaiyzing  risks. 

5.  Evaluate  proposed  suppliers’  abilities  to  perform  the  work. 

;  Examples  of  methods  used  to  evaluate  the  proposed  supplier’s  abilities  to  perform  the 
i  work  include  the  following: 

;  •  Evaluation  of  prior  experience  in  similar  applications 

;  •  Evaluation  of  customer  satisfaction  with  similar  products  provided 

i  •  Evaluation  of  prior  performance  on  similar  work 

i  •  Evaluation  of  management  capabilities 

I  •  Capability  evaluations 

I  •  Evaluation  of  staff  available  to  perform  the  work 

;  •  Evaluation  of  available  facilities  and  resources 

;  •  Evaluation  of  the  project's  ability  to  work  with  the  proposed  supplier 

I  •  Evaluation  of  the  impact  of  candidate  COTS  products  on  the  project's  plan  and 
I  commitments 

^ - 

I  When  modified  COTS  products  are  being  evaluated,  consider  the  following: 

I  •  Cost  of  the  modified  COTS  products 

j  •  Cost  and  effort  to  incorporate  the  modified  COTS  products  into  the  project 
I  •  Security  requirements 

I  •  Benefits  and  impacts  that  can  result  from  future  product  releases 


Future  releases  of  the  modified  COTS  product  can  provide  additional  features  that 
support  planned  or  anticipated  enhancements  for  the  project,  but  can  result  in  the 
supplier  discontinuing  support  of  its  current  release. 

6.  Select  the  supplier. 

SP  1 .3  Establish  Supplier  Agreements 

Establish  and  maintain  supplier  agreements. 

A  supplier  agreement  is  any  written  agreement  between  the  organization 
(representing  the  project)  and  the  supplier.  This  agreement  can  be  a 
contract,  license,  service  level  agreement,  or  memorandum  of  agreement. 

The  content  of  the  supplier  agreement  should  specify  the  arrangement  for 
selecting  supplier  processes  and  work  products  to  be  monitored,  analyzed, 
and  evaluated,  if  the  arrangement  is  appropriate  to  the  acquisition  or 
product  being  acquired.  The  supplier  agreement  should  also  specify  the 
reviews,  monitoring,  evaluations,  and  acceptance  testing  to  be  performed. 

Supplier  processes  that  are  critical  to  the  success  of  the  project  (e.g.,  due 
to  complexity,  due  to  importance)  should  be  monitored. 

Supplier  agreements  between  independent  legal  entities  are  typically 
reviewed  by  legal  or  contract  advisors  prior  to  approval. 
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Example  Work  Products 

1 .  Statements  of  work 

2.  Contracts 

3.  Memoranda  of  agreement 

4.  Licensing  agreement 
Subpractices 

1 .  Revise  the  requirements  (e.g.,  product  requirements,  service  level 
requirements)  to  be  fulfilled  by  the  supplier  to  reflect  negotiations  with 
the  supplier  when  necessary. 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  developing  product  requirements. 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements  of  the  project’s  products  and 
product  components  and  to  ensure  alignment  between  those 
requirements  and  the  project’s  plans  and  work  products. 

2.  Document  what  the  project  will  provide  to  the  supplier. 

Include  the  following: 

•  Project  furnished  facilities 

•  Documentation 

•  Services 

3.  Document  the  supplier  agreement. 

The  supplier  agreement  should  include  a  statement  of  work,  a  specification,  terms  and 
conditions,  a  list  of  deliverables,  a  schedule,  a  budget,  and  a  defined  acceptance 
process. 

;  This  subpractice  typically  includes  the  following  tasks: 

;  •  Identifying  the  type  and  depth  of  project  oversight  of  the  supplier,  procedures,  and 
I  evaluation  criteria  to  be  used  in  monitoring  supplier  performance  including  selection  of 
I  processes  to  be  monitored  and  work  products  to  be  evaluated 

I  •  Establishing  the  statement  of  work,  specification,  terms  and  conditions,  list  of 
I  deliverables,  schedule,  budget,  and  acceptance  process 

I  •  Identifying  who  from  the  project  and  supplier  are  responsible  and  authorized  to  make 
I  changes  to  the  supplier  agreement 

I  •  Identifying  how  requirements  changes  and  changes  to  the  supplier  agreement  are  to 
I  be  determined,  communicated,  and  addressed 

I  •  Identifying  standards  and  procedures  that  will  be  followed 
I  •  Identifying  critical  dependencies  between  the  project  and  the  supplier 
:  •  Identifying  the  types  of  reviews  that  will  be  conducted  with  the  supplier 

I  •  Identifying  the  supplier's  responsibilities  for  ongoing  maintenance  and  support  of  the 
I  acquired  products 

i  •  Identifying  warranty,  ownership,  and  rights  of  use  for  the  acquired  products 
[  •  Identifying  acceptance  criteria 
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In  some  cases,  selection  of  modified  COTS  products  can  require  a  supplier  agreement 
in  addition  to  the  agreements  in  the  product’s  license.  Examples  of  what  could  be 
covered  in  an  agreement  with  a  COTS  supplier  include  the  following: 

•  Discounts  for  large  quantity  purchases 

•  Coverage  of  relevant  stakeholders  under  the  licensing  agreement,  including  project 
suppliers,  team  members,  and  the  project's  customer 

•  Plans  for  future  enhancements 

•  On-site  support,  such  as  responses  to  queries  and  problem  reports 

•  Additional  capabilities  that  are  not  in  the  product 

•  Maintenance  support,  including  support  after  the  product  is  withdrawn  from  general 
availability 


4.  Periodically  review  the  supplier  agreement  to  ensure  it  accurately 
reflects  the  project’s  relationship  with  the  supplier  and  current  risks  and 
market  conditions. 

5.  Ensure  that  all  parties  to  the  supplier  agreement  understand  and  agree 
to  all  requirements  before  implementing  the  agreement  or  any 
changes. 

6.  Revise  the  supplier  agreement  as  necessary  to  reflect  changes  to  the 
supplier’s  processes  or  work  products. 

7.  Revise  the  project’s  plans  and  commitments,  including  changes  to  the 
project’s  processes  or  work  products,  as  necessary  to  reflect  the 
supplier  agreement. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  monitoring  commitments. 

SG  2 _ Satisfy  Supplier  Agreements _ 

Agreements  with  suppliers  are  satisfied  by  both  the  project  and  the  supplier. 

SP  2.1  Execute  the  Supplier  Agreement 

Perform  activities  with  the  supplier  as  specified  in  the  supplier 
agreement. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  providing  an  understanding  of  the  project’s  progress  so 
that  appropriate  corrective  actions  can  be  taken  when  the  project’s 
performance  deviates  significantiy  from  the  pian. 

Example  Work  Products 

1 .  Supplier  progress  reports  and  performance  measures 

2.  Supplier  review  materials  and  reports 

3.  Action  items  tracked  to  closure 

4.  Product  and  documentation  deliveries 
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Subpractices 

1 .  Monitor  supplier  progress  and  performance  (e.g.,  schedule,  effort,  cost, 
technical  performance)  as  defined  in  the  supplier  agreement. 

2.  Select,  monitor,  and  analyze  processes  used  by  the  supplier  as 
defined  in  the  supplier  agreement. 

Supplier  processes  that  are  critical  to  the  success  of  the  project  (e.g.,  due  to 
complexity,  due  to  importance)  should  be  monitored.  The  selection  of  processes  to 
monitor  should  consider  the  impact  of  the  selection  on  the  supplier. 

3.  Select  and  evaluate  work  products  from  the  supplier  as  defined  in  the 
supplier  agreement. 

The  work  products  selected  for  evaluation  should  include  critical  products,  product 
components,  and  work  products  that  provide  insight  into  quality  issues  as  early  as 
possible.  In  situations  of  low  risk,  it  may  not  be  necessary  to  select  any  work  products 
for  evaluation. 

4.  Conduct  reviews  with  the  supplier  as  specified  in  the  supplier 
agreement. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  conducting  miiestone  reviews  and  conducting 
progress  reviews. 

Reviews  cover  both  formal  and  informal  reviews  and  include  the  following  steps: 

•  Preparing  for  the  review 

•  Ensuring  that  relevant  stakeholders  participate 

•  Conducting  the  review 

•  Identifying,  documenting,  and  tracking  all  action  items  to  closure 

•  Preparing  and  distributing  to  the  relevant  stakeholders  a  summary  report  of  the  review 

5.  Conduct  technical  reviews  with  the  supplier  as  defined  in  the  supplier 
agreement. 

;  Technical  reviews  typically  include  the  following: 

;  •  Providing  the  supplier  with  visibility  into  the  needs  and  desires  of  the  project's 
I  customers  and  end  users  as  appropriate 

;  •  Reviewing  the  supplier's  technical  activities  and  verifying  that  the  supplier's 
I  interpretation  and  implementation  of  the  requirements  are  consistent  with  the  project's 
I  interpretation 

I  •  Ensuring  that  technical  commitments  are  being  met  and  that  technical  issues  are 
I  communicated  and  resolved  in  a  timely  manner 

I  •  Obtaining  technical  information  about  the  supplier's  products 
I  •  Providing  appropriate  technical  information  and  support  to  the  supplier 

6.  Conduct  management  reviews  with  the  supplier  as  defined  in  the 
supplier  agreement. 
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I  Management  reviews  typically  include  the  following: 

I  •  Reviewing  critical  dependencies 
I  •  Reviewing  project  risks  involving  the  supplier 
I  •  Reviewing  schedule  and  budget 

•  Reviewing  the  supplier's  compliance  with  legal  and  regulatoiy  requirements 


Technical  and  management  reviews  can  be  coordinated  and  held  jointly. 

7.  Use  the  results  of  reviews  to  improve  the  supplier’s  performance  and  to 
establish  and  nurture  long-term  relationships  with  preferred  suppliers. 

8.  Monitor  risks  involving  the  supplier  and  take  corrective  action  as 
necessary. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  monitoring  project  risks. 

SP  2.2  Accept  the  Acquired  Product 

Ensure  that  the  supplier  agreement  is  satisfied  before  accepting 
the  acquired  product. 

Acceptance  reviews,  tests,  and  configuration  audits  should  be  completed 
before  accepting  the  product  as  defined  in  the  supplier  agreement. 

Example  Work  Products 

1 .  Acceptance  procedures 

2.  Acceptance  reviews  or  test  results 

3.  Discrepancy  reports  or  corrective  action  plans 
Subpractices 

1 .  Define  the  acceptance  procedures. 

2.  Review  and  obtain  agreement  from  relevant  stakeholders  on  the 
acceptance  procedures  before  the  acceptance  review  or  test. 

3.  Verify  that  the  acquired  products  satisfy  their  requirements. 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  seiected  work  products. 

4.  Confirm  that  the  nontechnical  commitments  associated  with  the 
acquired  work  product  are  satisfied. 

This  confirmation  can  include  confirming  that  the  appropriate  license,  warranty, 
ownership,  use,  and  support  or  maintenance  agreements  are  in  place  and  that  all 
supporting  materials  are  received. 

5.  Document  the  results  of  the  acceptance  review  or  test. 

6.  Establish  an  action  plan  and  obtain  supplier  agreement  to  take  action 
to  correct  acquired  work  products  that  do  not  pass  their  acceptance 
review  or  test. 

7.  Identify,  document,  and  track  action  items  to  closure. 
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Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  managing  corrective  action  to  ciosure. 

SP  2.3  Ensure  Transition  of  Products 

Ensure  the  transition  of  products  acquired  from  the  suppiier. 

Before  the  acquired  product  is  transferred  to  the  project,  customer,  or  end 
user,  appropriate  preparation  and  evaluation  should  occur  to  ensure  a 
smooth  transition. 

Refer  to  the  Product  integration  process  area  for  more  information  about 
assembiing  product  components. 

Example  Work  Products 

1.  Transition  plans 

2.  Training  reports 

3.  Support  and  maintenance  reports 
Subpractices 

1 .  Ensure  that  facilities  exist  to  receive,  store,  integrate,  and  maintain  the 
acquired  products  as  appropriate. 

2.  Ensure  that  appropriate  training  is  provided  for  those  who  are  involved 
in  receiving,  storing,  integrating,  and  maintaining  acquired  products. 

3.  Ensure  that  acquired  products  are  stored,  distributed,  and  integrated 
according  to  the  terms  and  conditions  specified  in  the  supplier 
agreement  or  license. 
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TECHNICAL  SOLUTION 


An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Technical  Solution  (TS)  is  to  select,  design,  and  implement 
solutions  to  requirements.  Solutions,  designs,  and  implementations 
encompass  products,  product  components,  and  product  related  lifecycle 
processes  either  singly  or  in  combination  as  appropriate. 


Introductory  Notes 


The  Technical  Solution  process  area  is  applicable  at  any  level  of  the 
product  architecture  and  to  every  product,  product  component,  and  product 
related  lifecycle  process.  Throughout  the  process  areas,  where  the  terms 
“product”  and  “product  component”  are  used,  their  intended  meanings  also 
encompass  services,  service  systems,  and  their  components. 

This  process  area  focuses  on  the  following: 

•  Evaluating  and  selecting  solutions  (sometimes  referred  to  as  “design 
approaches,”  “design  concepts,”  or  “preliminary  designs”)  that 
potentially  satisfy  an  appropriate  set  of  allocated  functional  and  quality 
attribute  requirements 

•  Developing  detailed  designs  for  the  selected  solutions  (detailed  in  the 
context  of  containing  all  the  information  needed  to  manufacture,  code, 
or  otherwise  implement  the  design  as  a  product  or  product  component) 

•  Implementing  the  designs  as  a  product  or  product  component 

Typically,  these  activities  interactively  support  each  other.  Some  level  of 
design,  at  times  fairly  detailed,  can  be  needed  to  select  solutions. 
Prototypes  or  pilots  can  be  used  as  a  means  of  gaining  sufficient 
knowledge  to  develop  a  technical  data  package  or  a  complete  set  of 
requirements.  Quality  attribute  models,  simulations,  prototypes  or  pilots  can 
be  used  to  provide  additional  information  about  the  properties  of  the 
potential  design  solutions  to  aid  in  the  selection  of  solutions.  Simulations 
can  be  particularly  useful  for  projects  developing  systems-of-systems. 

Technical  Solution  specific  practices  apply  not  only  to  the  product  and 
product  components  but  also  to  product  related  lifecycle  processes.  The 
product  related  lifecycle  processes  are  developed  in  concert  with  the 
product  or  product  component.  Such  development  can  include  selecting 
and  adapting  existing  processes  (including  standard  processes)  for  use  as 
well  as  developing  new  processes. 

Processes  associated  with  the  Technical  Solution  process  area  receive  the 
product  and  product  component  requirements  from  the  requirements 
management  processes.  The  requirements  management  processes  place 
the  requirements,  which  originate  in  requirements  development  processes. 
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under  appropriate  configuration  management  and  maintain  their  traceability 
to  previous  requirements. 

For  a  maintenance  or  sustainment  project,  the  requirements  in  need  of 
maintenance  actions  or  redesign  can  be  driven  by  user  needs,  technology 
maturation  and  obsolescence,  or  latent  defects  in  the  product  components. 
New  requirements  can  arise  from  changes  in  the  operating  environment. 
Such  requirements  can  be  uncovered  during  verification  of  the  product(s) 
where  its  actual  performance  can  be  compared  against  its  specified 
performance  and  unacceptable  degradation  can  be  identified.  Processes 
associated  with  the  Technical  Solution  process  area  should  be  used  to 
perform  the  maintenance  or  sustainment  design  efforts. 

For  product  lines,  these  practices  apply  to  both  core  asset  development 
(i.e.,  building  for  reuse)  and  product  development  (i.e.,  building  with  reuse). 
Core  asset  development  additionally  requires  product  line  variation 
management  (the  selection  and  implementation  of  product  line  variation 
mechanisms)  and  product  line  production  planning  (the  development  of 
processes  and  other  work  products  that  define  how  products  will  be  built  to 
make  best  use  of  these  core  assets). 

In  Agile  environments,  the  focus  is  on  early  solution  exploration.  By  making  the  selection 
and  tradeoff  decisions  more  explicit,  the  Technical  Solution  process  area  helps  improve  the 
quality  of  those  decisions,  both  individually  and  over  time.  Solutions  can  be  defined  in  terms 
of  functions,  feature  sets,  releases,  or  any  other  components  that  facilitate  product 
development.  When  someone  other  than  the  team  will  be  working  on  the  product  in  the 
future,  release  information,  maintenance  logs,  and  other  data  are  typically  included  with  the 
installed  product.  To  support  future  product  updates,  rationale  (for  trade-offs,  interfaces,  and 
purchased  parts)  is  captured  so  that  why  the  product  exists  can  be  better  understood.  If 
there  is  low  risk  in  the  selected  solution,  the  need  to  formally  capture  decisions  is 
significantly  reduced.  (See  ‘‘Interpreting  CMMI  When  Using  Agile  Approaches”  in  Part  I.) 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more  information 
about  allocating  product  component  requirements,  establishing  operational 
concepts  and  scenarios,  and  identifying  interface  requirements. 

Refer  to  the  Verification  process  area  for  more  information  about  performing 
peer  reviews  and  verifying  selected  work  products. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  analyzing  possible  decisions  using  a  formal  evaluation 
process  that  evaluates  identified  alternatives  against  established  criteria. 

Refer  to  the  Organizational  Performance  Management  process  area  for 
more  information  about  selecting  improvements  and  deploying 
improvements. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  managing  requirements  of  the  project’s  products  and  product 
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components  and  ensuring  alignment  between  those  requirements  and  the 
project’s  plans  and  work  products. 

Specific  Goai  and  Practice  Summary 

SG  1  Select  Product  Component  Solutions 

SP  1 .1  Develop  Alternative  Solutions  and  Selection  Criteria 
SP  1 .2  Select  Product  Component  Solutions 
SG  2  Develop  the  Design 

SP  2.1  Design  the  Product  or  Product  Component 
SP  2.2  Establish  a  Technical  Data  Package 
SP  2.3  Design  Interfaces  Using  Criteria 
SP  2.4  Perform  Make,  Buy,  or  Reuse  Analyses 
SG  3  Implement  the  Product  Design 
SP  3.1  Implement  the  Design 

SP  3.2  Develop  Product  Support  Documentation 

Specific  Practices  by  Goai 


SG  1 _ Select  Product  Component  Solutions _ 

Product  or  product  component  solutions  are  selected  from  alternative 
solutions. 

Alternative  solutions  and  their  relative  merits  are  considered  in  advance  of 
selecting  a  solution.  Key  requirements,  design  issues,  and  constraints  are 
established  for  use  in  alternative  solution  analysis.  Architectural  choices 
and  patterns  that  support  achievement  of  quality  attribute  requirements  are 
considered.  Also,  the  use  of  commercial  off-the-shelf  (COTS)  product 
components  are  considered  relative  to  cost,  schedule,  performance,  and 
risk.  COTS  alternatives  can  be  used  with  or  without  modification. 
Sometimes  such  items  can  require  modifications  to  aspects  such  as 
interfaces  or  a  customization  of  some  of  the  features  to  correct  a  mismatch 
with  functional  or  quality  attribute  requirements,  or  with  architectural 
designs. 

One  indicator  of  a  good  design  process  is  that  the  design  was  chosen  after 
comparing  and  evaluating  it  against  alternative  solutions.  Decisions  about 
architecture,  custom  development  versus  off  the  shelf,  and  product 
component  modularization  are  typical  of  the  design  choices  that  are 
addressed.  Some  of  these  decisions  can  require  the  use  of  a  formal 
evaluation  process. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  analyzing  possible  decisions  using  a  formal  evaluation 
process  that  evaluates  identified  alternatives  against  established  criteria. 

Sometimes  the  search  for  solutions  examines  alternative  instances  of  the 
same  requirements  with  no  allocations  needed  for  lower  level  product 
components.  Such  is  the  case  at  the  bottom  of  the  product  architecture. 
There  are  also  cases  where  one  or  more  of  the  solutions  are  fixed  (e.g.,  a 
specific  solution  is  directed  or  available  product  components,  such  as 
COTS,  are  investigated  for  use). 
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In  the  general  case,  solutions  are  defined  as  a  set.  That  is,  when  defining 
the  next  layer  of  product  components,  the  solution  for  each  of  the  product 
components  in  the  set  is  established.  The  alternative  solutions  are  not  only 
different  ways  of  addressing  the  same  requirements,  but  they  also  reflect  a 
different  allocation  of  requirements  among  the  product  components 
comprising  the  solution  set.  The  objective  is  to  optimize  the  set  as  a  whole 
and  not  the  individual  pieces.  There  will  be  significant  interaction  with 
processes  associated  with  the  Requirements  Development  process  area  to 
support  the  provisional  allocations  to  product  components  until  a  solution 
set  is  selected  and  final  allocations  are  established. 

Product  related  lifecycle  processes  are  among  the  product  component 
solutions  that  are  selected  from  alternative  solutions.  Examples  of  these 
product  related  lifecycle  processes  are  the  manufacturing,  delivery,  and 
support  processes. 

SP  1 .1  Develop  Alternative  Solutions  and  Selection  Criteria 

Develop  alternative  solutions  and  selection  criteria. 

Refer  to  the  Allocate  Product  Component  Requirements  specific  practice  In 
the  Requirements  Development  process  area  for  more  Information  about 
obtaining  allocations  of  requirements  to  solution  alternatives  for  the  product 
components. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
Information  about  establishing  evaluation  criteria. 

Alternative  solutions  should  be  identified  and  analyzed  to  enable  the 
selection  of  a  balanced  solution  across  the  life  of  the  product  in  terms  of 
cost,  schedule,  performance,  and  risk.  These  solutions  are  based  on 
proposed  product  architectures  that  address  critical  product  quality  attribute 
requirements  and  span  a  design  space  of  feasible  solutions.  Specific 
practices  associated  with  the  Develop  the  Design  specific  goal  provide 
more  information  on  developing  potential  product  architectures  that  can  be 
incorporated  into  alternative  solutions  for  the  product. 

Alternative  solutions  frequently  encompass  alternative  requirement 
allocations  to  different  product  components.  These  alternative  solutions  can 
also  include  the  use  of  COTS  solutions  in  the  product  architecture. 
Processes  associated  with  the  Requirements  Development  process  area 
would  then  be  employed  to  provide  a  more  complete  and  robust  provisional 
allocation  of  requirements  to  the  alternative  solutions. 

Alternative  solutions  span  the  acceptable  range  of  cost,  schedule,  and 
performance.  The  product  component  requirements  are  received  and  used 
along  with  design  issues,  constraints,  and  criteria  to  develop  the  alternative 
solutions.  Selection  criteria  would  typically  address  costs  (e.g.,  time, 
people,  money),  benefits  (e.g.,  product  performance,  capability, 
effectiveness),  and  risks  (e.g.,  technical,  cost,  schedule).  Considerations  for 
alternative  solutions  and  selection  criteria  include  the  following: 

•  Cost  of  development,  manufacturing,  procurement,  maintenance,  and 
support 
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•  Achievement  of  key  quality  attribute  requirements,  such  as  product 
timeliness,  safety,  reliability,  and  maintainability 

•  Complexity  of  the  product  component  and  product  related  lifecycle 
processes 

•  Robustness  to  product  operating  and  use  conditions,  operating  modes, 
environments,  and  variations  in  product  related  lifecycle  processes 

•  Product  expansion  and  growth 

•  Technology  limitations 

•  Sensitivity  to  construction  methods  and  materials 

•  Risk 

•  Evolution  of  requirements  and  technology 

•  Disposal 

•  Capabilities  and  limitations  of  end  users  and  operators 

•  Characteristics  of  COTS  products 

The  considerations  listed  here  are  a  basic  set;  organizations  should 
develop  screening  criteria  to  narrow  down  the  list  of  alternatives  that  are 
consistent  with  their  business  objectives.  Product  lifecycle  cost,  while  being 
a  desirable  parameter  to  minimize,  can  be  outside  the  control  of 
development  organizations.  A  customer  may  not  be  willing  to  pay  for 
features  that  cost  more  in  the  short  term  but  ultimately  decrease  cost  over 
the  life  of  the  product.  In  such  cases,  customers  should  at  least  be  advised 
of  any  potential  for  reducing  lifecycle  costs.  The  criteria  used  to  select  final 
solutions  should  provide  a  balanced  approach  to  costs,  benefits,  and  risks. 

Example  Work  Products 

1 .  Alternative  solution  screening  criteria 

2.  Evaluation  reports  of  new  technologies 

3.  Alternative  solutions 

4.  Selection  criteria  for  final  selection 

5.  Evaluation  reports  of  COTS  products 
Subpractices 

1 .  Identify  screening  criteria  to  select  a  set  of  alternative  solutions  for 
consideration. 

2.  Identify  technologies  currently  in  use  and  new  product  technologies  for 
competitive  advantage. 

Refer  to  the  Organizational  Performance  Management  process  area 
for  more  information  about  selecting  improvements  and  deploying 
improvements. 

The  project  should  identify  technologies  applied  to  current  products  and  processes  and 
monitor  the  progress  of  currently  used  technologies  throughout  the  life  of  the  project. 
The  project  should  identify,  select,  evaluate,  and  invest  in  new  technologies  to  achieve 
competitive  advantage.  Alternative  solutions  could  include  newly  developed 
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technologies,  but  could  also  include  applying  mature  technologies  in  different 
applications  or  to  maintain  current  methods. 

3.  Identify  candidate  COTS  products  that  satisfy  the  requirements. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  selecting  suppliers. 

The  supplier  of  the  COTS  product  will  need  to  meet  requirements  that  include  the 
following: 

•  Product  functionality  and  quality  attributes 

•  Terms  and  conditions  of  warranties  for  the  products 

•  Expectations  (e.g.,  for  review  activities),  constraints,  or  checkpoints  to  help  mitigate 
suppliers'  responsibilities  for  ongoing  maintenance  and  support  of  the  products 

4.  Identify  re-usable  solution  components  or  applicable  architecture 
patterns. 

For  product  lines,  the  organization’s  core  assets  can  be  used  as  a  basis  for  a  solution. 

5.  Generate  alternative  solutions. 

6.  Obtain  a  complete  requirements  allocation  for  each  alternative. 

7.  Develop  the  criteria  for  selecting  the  best  alternative  solution. 

Criteria  should  be  included  that  address  design  issues  for  the  life  of  the  product,  such 
as  provisions  for  more  easily  inserting  new  technologies  or  the  ability  to  better  exploit 
commercial  products.  Examples  include  criteria  related  to  open  design  or  open 
architecture  concepts  for  the  alternatives  being  evaluated. 

SP  1.2  Select  Product  Component  Solutions 

Select  the  product  component  solutions  based  on  selection 
criteria. 

Refer  to  the  Allocate  Product  Component  Requirements  and  Identify 
Interface  Requirements  specific  practices  of  the  Requirements 
Development  process  area  for  more  information  about  establishing  the 
allocated  requirements  for  product  components  and  interface  requirements 
among  product  components. 

Selecting  product  components  that  best  satisfy  the  criteria  establishes  the 
requirement  allocations  to  product  components.  Lower  level  requirements 
are  generated  from  the  selected  alternative  and  used  to  develop  product 
component  designs.  Interfaces  among  product  components  are  described. 
Physical  interface  descriptions  are  included  in  the  documentation  for 
interfaces  to  items  and  activities  external  to  the  product. 

The  description  of  the  solutions  and  the  rationale  for  selection  are 
documented.  The  documentation  evolves  throughout  development  as 
solutions  and  detailed  designs  are  developed  and  those  designs  are 
implemented.  Maintaining  a  record  of  rationale  is  critical  to  downstream 
decision  making.  Such  records  keep  downstream  stakeholders  from 
redoing  work  and  provide  insights  to  apply  technology  as  it  becomes 
available  in  applicable  circumstances. 
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Example  Work  Products 

1 .  Product  component  selection  decisions  and  rationale 

2.  Documented  relationships  between  requirements  and  product 
components 

3.  Documented  solutions,  evaluations,  and  rationale 

Subpractices 

1 .  Evaluate  each  alternative  solution/set  of  solutions  against  the  selection 
criteria  established  in  the  context  of  the  operational  concepts  and 
scenarios. 

Develop  timeline  scenarios  for  product  operation  and  user  interaction  for  each 
alternative  solution. 

2.  Based  on  the  evaluation  of  alternatives,  assess  the  adequacy  of  the 
selection  criteria  and  update  these  criteria  as  necessary. 

3.  Identify  and  resolve  issues  with  the  alternative  solutions  and 
requirements. 

4.  Select  the  best  set  of  alternative  solutions  that  satisfy  the  established 
selection  criteria. 

5.  Establish  the  functional  and  quality  attribute  requirements  associated 
with  the  selected  set  of  alternatives  as  the  set  of  allocated 
requirements  to  those  product  components. 

6.  Identify  the  product  component  solutions  that  will  be  reused  or 
acquired. 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  managing  the  acquisition  of  products  and  services 
from  suppliers. 

7.  Establish  and  maintain  the  documentation  of  the  solutions,  evaluations, 
and  rationale. 

SG  2 _ Develop  the  Design _ 

Product  or  product  component  designs  are  developed. 

Product  or  product  component  designs  should  provide  the  appropriate 
content  not  only  for  implementation,  but  also  for  other  phases  of  the  product 
lifecycle  such  as  modification,  reprocurement,  maintenance,  sustainment, 
and  installation.  The  design  documentation  provides  a  reference  to  support 
mutual  understanding  of  the  design  by  relevant  stakeholders  and  supports 
future  changes  to  the  design  both  during  development  and  in  subsequent 
phases  of  the  product  lifecycle.  A  complete  design  description  is 
documented  in  a  technical  data  package  that  includes  a  full  range  of 
features  and  parameters  including  form,  fit,  function,  interface, 
manufacturing  process  characteristics,  and  other  parameters.  Established 
organizational  or  project  design  standards  (e.g.,  checklists,  templates, 
object  frameworks)  form  the  basis  for  achieving  a  high  degree  of  definition 
and  completeness  in  design  documentation. 
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SP  2.1  Design  the  Product  or  Product  Component 

Develop  a  design  for  the  product  or  product  component. 

Product  design  consists  of  two  broad  phases  that  can  overlap  in  execution: 
preliminary  and  detailed  design.  Preliminary  design  establishes  product 
capabilities  and  the  product  architecture,  including  architectural  styles  and 
patterns,  product  partitions,  product  component  identifications,  system 
states  and  modes,  major  intercomponent  interfaces,  and  external  product 
interfaces.  Detailed  design  fully  defines  the  structure  and  capabilities  of  the 
product  components. 

Refer  to  the  Establish  a  Definition  of  Required  Functionality  and  Quality 
Attributes  specific  practice  in  the  Requirements  Development  process  area 
for  more  information  about  developing  architectural  requirements. 

Architecture  definition  is  driven  from  a  set  of  architectural  requirements 
developed  during  the  requirements  development  processes.  These 
requirements  identify  the  quality  attributes  that  are  critical  to  the  success  of 
the  product.  The  architecture  defines  structural  elements  and  coordination 
mechanisms  that  either  directly  satisfy  requirements  or  support  the 
achievement  of  the  requirements  as  the  details  of  the  product  design  are 
established.  Architectures  can  include  standards  and  design  rules 
governing  development  of  product  components  and  their  interfaces  as  well 
as  guidance  to  aid  product  developers.  Specific  practices  in  the  Select 
Product  Component  Solutions  specific  goal  contain  more  information  about 
using  product  architectures  as  a  basis  for  alternative  solutions. 

Architects  postulate  and  develop  a  model  of  the  product,  making  judgments 
about  allocation  of  functional  and  quality  attribute  requirements  to  product 
components  including  hardware  and  software.  Multiple  architectures, 
supporting  alternative  solutions,  can  be  developed  and  analyzed  to 
determine  the  advantages  and  disadvantages  in  the  context  of  the 
architectural  requirements. 

Operational  concepts  and  operational,  sustainment,  and  development 
scenarios  are  used  to  generate  use  cases  and  quality  attribute  related 
scenarios  that  are  used  to  refine  the  architecture.  They  are  also  used  as  a 
means  to  evaluate  the  suitability  of  the  architecture  for  its  intended  purpose 
during  architecture  evaluations,  which  are  conducted  periodically 
throughout  product  design. 

Refer  to  the  Establish  Operational  Concepts  and  Scenarios  specific  practice 
in  the  Requirements  Development  process  area  for  more  information  about 
developing  operational  concepts  and  scenarios  used  in  architecture 
evaluation. 
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Examples  of  architecture  definition  tasks  include  the  following: 

•  Establishing  the  structural  relations  of  partitions  and  rules  regarding  interfaces  between 
elements  within  partitions,  and  between  partitions 

•  Selecting  architectural  patterns  that  support  the  functional  and  quality  attribute 
requirements,  and  instantiating  or  composing  those  patterns  to  create  the  product 
architecture 

•  Identifying  major  internal  interfaces  and  all  external  interfaces 

•  Identifying  product  components  and  interfaces  between  them 

•  Formally  defining  component  behavior  and  interaction  using  an  architecture  description 
language 

•  Defining  coordination  mechanisms  (e.g.,  for  software,  hardware) 

•  Establishing  infrastructure  capabilities  and  services 

•  Developing  product  component  templates  or  classes  and  frameworks 

•  Establishing  design  rules  and  authority  for  making  decisions 

•  Defining  a  process/thread  model 

•  Defining  physical  deployment  of  software  to  hardware 

•  Identifying  major  reuse  approaches  and  sources 


During  detailed  design,  the  product  architecture  details  are  finalized, 
product  components  are  completely  defined,  and  interfaces  are  fully 
characterized.  Product  component  designs  can  be  optimized  for  certain 
quality  attributes.  Designers  can  evaluate  the  use  of  legacy  or  COTS 
products  for  the  product  components.  As  the  design  matures,  the 
requirements  assigned  to  lower  level  product  components  are  tracked  to 
ensure  that  those  requirements  are  satisfied. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  ensuring  aiignment  between  project  work  and  requirements. 

For  software  engineering,  detailed  design  is  focused  on  software  product 
component  development.  The  internal  structure  of  product  components  is 
defined,  data  schemas  are  generated,  algorithms  are  developed,  and 
heuristics  are  established  to  provide  product  component  capabilities  that 
satisfy  allocated  requirements. 

For  hardware  engineering,  detailed  design  is  focused  on  product 
development  of  electronic,  mechanical,  electro-optical,  and  other  hardware 
products  and  their  components.  Electrical  schematics  and  interconnection 
diagrams  are  developed,  mechanical  and  optical  assembly  models  are 
generated,  and  fabrication  and  assembly  processes  are  developed. 

Example  Work  Products 

1.  Product  architecture 

2.  Product  component  design 
Subpractices 

1 .  Establish  and  maintain  criteria  against  which  the  design  can  be 
evaluated. 
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Examples  of  quality  attributes,  in  addition  to  expected  product  performance,  for  which 
design  criteria  can  be  established,  include  the  following: 

•  Modular 

•  Clear 

•  Simple 

•  Maintainable 

•  Verifiable 

•  Portable 

•  Reliable 

•  Accurate 

•  Secure 

•  Scalable 

•  Usable 


2.  Identify,  develop,  or  acquire  the  design  methods  appropriate  for  the 
product. 

Effective  design  methods  can  embody  a  wide  range  of  activities,  tools,  and  descriptive 
techniques.  Whether  a  given  method  is  effective  or  not  depends  on  the  situation.  Two 
companies  may  have  effective  design  methods  for  products  in  which  they  specialize, 
but  these  methods  may  not  be  effective  in  cooperative  ventures.  Highly  sophisticated 
methods  are  not  necessarily  effective  in  the  hands  of  designers  who  have  not  been 
trained  in  the  use  of  the  methods. 

Whether  a  method  is  effective  also  depends  on  how  much  assistance  it  provides  the 
designer,  and  the  cost  effectiveness  of  that  assistance.  For  example,  a  multiyear 
prototyping  effort  may  not  be  appropriate  for  a  simple  product  component  but  might  be 
the  right  thing  to  do  for  an  unprecedented,  expensive,  and  complex  product 
development.  Rapid  prototyping  techniques,  however,  can  be  highly  effective  for  many 
product  components.  Methods  that  use  tools  to  ensure  that  a  design  will  encompass 
all  the  necessary  attributes  needed  to  implement  the  product  component  design  can 
be  effective.  For  example,  a  design  tool  that  "knows”  the  capabilities  of  the 
manufacturing  processes  can  allow  the  variability  of  the  manufacturing  process  to  be 
accounted  for  in  the  design  tolerances. 

;  Examples  of  techniques  and  methods  that  facilitate  effective  design  include  the 
:  following: 

I  •  Prototypes 
i  •  Structural  models 
i  •  Object  oriented  design 
i  •  Essential  systems  analysis 
;  •  Entity  relationship  models 
;  •  Design  reuse 
i  •  Design  patterns 


3.  Ensure  that  the  design  adheres  to  applicable  design  standards  and 
criteria. 
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Examples  of  design  standards  include  the  following  (some  or  all  of  these  standards 
may  be  design  criteria,  particularly  in  circumstances  where  the  standards  have  not 
been  established): 

•  Operator  interface  standards 

•  Test  scenarios 

•  Safety  standards 

•  Design  constraints  (e.g.,  electromagnetic  compatibility,  signal  integrity,  environmental) 

•  Production  constraints 

•  Design  tolerances 

•  Parts  standards  (e.g.,  production  scrap,  waste) 


4.  Ensure  that  the  design  adheres  to  allocated  requirements. 

Identified  COTS  product  components  should  be  taken  into  account.  For  example, 
putting  existing  product  components  into  the  product  architecture  might  modify  the 
requirements  and  the  requirements  allocation. 

5.  Document  the  design. 

SP  2.2  Establish  a  Technical  Data  Package 

Establish  and  maintain  a  technical  data  package. 

A  technical  data  package  provides  the  developer  with  a  comprehensive 
description  of  the  product  or  product  component  as  it  is  developed.  Such  a 
package  also  provides  procurement  flexibility  in  a  variety  of  circumstances 
such  as  performance  based  contracting  or  build-to-print.  (See  the  definition 
of  “technical  data  package”  in  the  glossary.) 

The  design  is  recorded  in  a  technical  data  package  that  is  created  during 
preliminary  design  to  document  the  architecture  definition.  This  technical 
data  package  is  maintained  throughout  the  life  of  the  product  to  record 
essential  details  of  the  product  design.  The  technical  data  package  provides 
the  description  of  a  product  or  product  component  (including  product  related 
lifecycle  processes  if  not  handled  as  separate  product  components)  that 
supports  an  acquisition  strategy,  or  the  implementation,  production, 
engineering,  and  logistics  support  phases  of  the  product  lifecycle.  The 
description  includes  the  definition  of  the  required  design  configuration  and 
procedures  to  ensure  adequacy  of  product  or  product  component 
performance.  It  includes  all  applicable  technical  data  such  as  drawings, 
associated  lists,  specifications,  design  descriptions,  design  databases, 
standards,  quality  attribute  requirements,  quality  assurance  provisions,  and 
packaging  details.  The  technical  data  package  includes  a  description  of  the 
selected  alternative  solution  that  was  chosen  for  implementation. 


Technical  Solution  (TS) 


383 


CMMI  for  Development,  Version  1.3 


Because  design  descriptions  can  involve  a  large  amount  of  data  and  can  be 
crucial  to  successful  product  component  development,  it  is  advisable  to 
establish  criteria  for  organizing  the  data  and  for  selecting  the  data  content. 

It  is  particularly  useful  to  use  the  product  architecture  as  a  means  of 
organizing  this  data  and  abstracting  views  that  are  clear  and  relevant  to  an 
issue  or  feature  of  interest.  These  views  include  the  following: 

•  Customers 

•  Requirements 

•  The  environment 

•  Functional 

•  Logical 

•  Security 

•  Data 

•  States/modes 

•  Construction 

•  Management 

These  views  are  documented  in  the  technical  data  package. 

Example  Work  Products 

1 .  Technical  data  package 

Subpractices 

1 .  Determine  the  number  of  levels  of  design  and  the  appropriate  level  of 
documentation  for  each  design  level. 

Determining  the  number  of  levels  of  product  components  (e.g.,  subsystem,  hardware 
configuration  Item,  circuit  board,  computer  software  configuration  item  [CSCI], 
computer  software  product  component,  computer  software  unit)  that  require 
documentation  and  requirements  traceability  is  important  to  manage  documentation 
costs  and  to  support  integration  and  verification  plans. 

2.  Determine  the  views  to  be  used  to  document  the  architecture. 

Views  are  selected  to  document  the  structures  inherent  in  the  product  and  to  address 
particular  stakeholder  concerns. 

3.  Base  detailed  design  descriptions  on  the  allocated  product  component 
requirements,  architecture,  and  higher  level  designs. 

4.  Document  the  design  in  the  technical  data  package. 

5.  Document  the  key  (i.e.,  significant  effect  on  cost,  schedule,  or  technical 
performance)  decisions  made  or  defined,  including  their  rationale. 

6.  Revise  the  technical  data  package  as  necessary. 
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SP  2.3  Design  Interfaces  Using  Criteria 

Design  product  component  interfaces  using  estabiished  criteria. 

Interface  designs  include  the  following: 

•  Origination 

•  Destination 

•  Stimulus  and  data  characteristics  for  software,  including  sequencing 
constraints  or  protocols 

•  Resources  consumed  processing  a  particular  stimulus 

•  Exception  or  error  handling  behavior  for  stimuli  that  are  erroneous  or 
out  of  specified  limits 

•  Electrical,  mechanical,  and  functional  characteristics  for  hardware 

•  Services  lines  of  communication 

The  criteria  for  interfaces  frequently  reflect  critical  parameters  that  should 
be  defined,  or  at  least  investigated,  to  ascertain  their  applicability.  These 
parameters  are  often  peculiar  to  a  given  type  of  product  (e.g.,  software, 
mechanical,  electrical,  service)  and  are  often  associated  with  safety, 
security,  durability,  and  mission  critical  characteristics. 

Refer  to  the  Identify  Interface  Requirements  specific  practice  in  the 
Requirements  Development  process  area  for  more  information  about 
identifying  product  and  product  component  interface  requirements. 

Example  Work  Products 

1 .  Interface  design  specifications 

2.  Interface  control  documents 

3.  Interface  specification  criteria 

4.  Rationale  for  selected  interface  design 
Subpractices 

1 .  Define  interface  criteria. 

These  criteria  can  be  a  part  of  the  organizational  process  assets. 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  and  maintaining  a  usable  set  of 
organizational  process  assets  and  work  environment  standards. 

2.  Identify  interfaces  associated  with  other  product  components. 

3.  Identify  interfaces  associated  with  external  items. 

4.  Identify  interfaces  between  product  components  and  the  product 
related  lifecycle  processes. 

For  example,  such  interfaces  could  include  the  ones  between  a  product  component  to 
be  fabricated  and  the  jigs  and  fixtures  used  to  enable  that  fabrication  during  the 
manufacturing  process. 

5.  Apply  the  criteria  to  the  interface  design  alternatives. 
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Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai 
evaiuation  process  that  evaiuates  identified  aiternatives  against 
estabiished  criteria. 

6.  Document  the  selected  interface  designs  and  the  rationale  for  the 
selection. 

SP  2.4  Perform  Make,  Buy,  or  Reuse  Analyses 

Evaluate  whether  the  product  components  should  be  developed, 
purchased,  or  reused  based  on  established  criteria. 

The  determination  of  what  products  or  product  components  will  be  acquired 
is  frequently  referred  to  as  a  “make-or-buy  analysis.”  It  is  based  on  an 
analysis  of  the  needs  of  the  project.  This  make-or-buy  analysis  begins  early 
in  the  project  during  the  first  iteration  of  design;  continues  during  the  design 
process;  and  is  completed  with  the  decision  to  develop,  acquire,  or  reuse 
the  product. 

Refer  to  the  Requirements  Deveiopment  process  area  for  more  information 
about  eiiciting,  anaiyzing,  and  estabiishing  customer,  product,  and  product 
component  requirements. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  managing  requirements. 

Factors  affecting  the  make-or-buy  decision  include  the  following: 

•  Functions  the  products  will  provide  and  how  these  functions  will  fit  into 
the  project 

•  Available  project  resources  and  skills 

•  Costs  of  acquiring  versus  developing  internally 

•  Critical  delivery  and  integration  dates 

•  Strategic  business  alliances,  including  high-level  business  requirements 

•  Market  research  of  available  products,  including  COTS  products 

•  Functionality  and  quality  of  available  products 

•  Skills  and  capabilities  of  potential  suppliers 

•  Impact  on  core  competencies 

•  Licenses,  warranties,  responsibilities,  and  limitations  associated  with 
products  being  acquired 

•  Product  availability 

•  Proprietary  issues 

•  Risk  reduction 

•  Match  between  needs  and  product  line  core  assets 

The  make-or-buy  decision  can  be  conducted  using  a  formal  evaluation 
approach. 

Refer  to  the  Decision  Anaiysis  and  Resoiution  process  area  for  more 
information  about  anaiyzing  possibie  decisions  using  a  formai  evaiuation 
process  that  evaiuates  identified  aiternatives  against  estabiished  criteria. 
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As  technology  evolves,  so  does  the  rationale  for  choosing  to  develop  or 
purchase  a  product  component.  While  complex  development  efforts  can 
favor  purchasing  an  off-the-shelf  product  component,  advances  in 
productivity  and  tools  can  provide  an  opposing  rationale.  Off-the-shelf 
products  can  have  incomplete  or  inaccurate  documentation  and  may  or 
may  not  be  supported  in  the  future. 

Once  the  decision  is  made  to  purchase  an  off-the-shelf  product  component, 
how  to  implement  that  decision  depends  on  the  type  of  item  being  acquired. 
There  are  times  when  “off  the  shelf”  refers  to  an  existing  item  that  is  not 
readily  available  because  it  must  first  be  customized  to  meet  particular 
purchaser  specified  requirements  for  performance  and  other  product 
characteristics  as  part  of  its  procurement  (e.g.,  aircraft  engines).  To 
manage  such  procurements,  a  supplier  agreement  is  established  that 
includes  these  requirements  and  the  acceptance  criteria  to  be  met.  In  other 
cases,  the  off-the-shelf  product  is  literally  off  the  shelf  (word  processing 
software,  for  example)  and  there  is  no  agreement  with  the  supplier  that 
needs  to  be  managed. 

Refer  to  the  Establish  Supplier  Agreements  specific  goal  in  the  Supplier 
Agreement  Management  process  area  for  more  information  about  handling 
supplier  agreements  for  modified  COTS  products. 

Example  Work  Products 

1 .  Criteria  for  design  and  product  component  reuse 

2.  Make-or-buy  analyses 

3.  Guidelines  for  choosing  COTS  product  components 
Subpractices 

1 .  Develop  criteria  for  the  reuse  of  product  component  designs. 

2.  Analyze  designs  to  determine  if  product  components  should  be 
developed,  reused,  or  purchased. 

3.  Analyze  implications  for  maintenance  when  considering  purchased  or 
nondevelopmental  (e.g.,  COTS,  government  off  the  shelf,  reuse)  items. 

:  Examples  of  implications  for  maintenance  include  the  following: 

I  •  Compatibility  with  future  releases  of  COTS  products 
i  •  Configuration  management  of  supplier  changes 
i  •  Defects  in  the  nondevelopmental  item  and  their  resolution 
i  •  Unplanned  obsolescence 


SG  3 _ Implement  the  Product  Design _ 

Product  components,  and  associated  support  documentation,  are 
impiemented  from  their  designs. 

Product  components  are  implemented  from  the  designs  established  by  the 
specific  practices  in  the  Develop  the  Design  specific  goal.  The 
implementation  usually  includes  unit  testing  of  the  product  components 
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before  sending  them  to  product  integration  and  development  of  end-user 
documentation. 

SP  3.1  Implement  the  Design 

Implement  the  designs  of  the  product  components. 

Once  the  design  has  been  completed,  it  is  implemented  as  a  product 
component.  The  characteristics  of  that  implementation  depend  on  the  type 
of  product  component. 

Design  implementation  at  the  top  level  of  the  product  hierarchy  involves  the 
specification  of  each  of  the  product  components  at  the  next  level  of  the 
product  hierarchy.  This  activity  includes  the  allocation,  refinement,  and 
verification  of  each  product  component.  It  also  involves  the  coordination 
between  the  various  product  component  development  efforts. 

Refer  to  the  Product  Integration  process  area  for  more  information  about 
managing  interfaces  and  assembling  product  components. 

Refer  to  the  Requirements  Development  process  area  for  more  information 
about  the  allocating  product  component  requirements  and  analyzing 
requirements. 

;  Example  characteristics  of  this  implementation  are  as  follows: 

i  •  Software  is  coded, 

i  •  Data  are  documented, 

i  •  Services  are  documented. 

I  •  Electrical  and  mechanical  parts  are  fabricated. 

;  •  Product-unique  manufacturing  processes  are  put  into  operation. 

;  •  Processes  are  documented, 

i  •  Facilities  are  constructed. 

i  •  Materials  are  produced  (e.g.,  a  product-unique  material  could  be  petroleum,  oil,  a 
;  lubricant,  a  new  alloy). 


Example  Work  Products 

1.  Implemented  design 

Subpractices 

1 .  Use  effective  methods  to  implement  the  product  components. 

^ - 

I  Examples  of  software  coding  methods  include  the  following: 

:  •  Structured  programming 
j  •  Object  oriented  programming 
I  •  Aspect  oriented  programming 
I  •  Automatic  code  generation 
i  •  Software  code  reuse 
i  •  Use  of  applicable  design  patterns 
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Examples  of  hardware  implementation  methods  include  the  following: 

•  Gate  level  synthesis 

•  Circuit  board  layout  (place  and  route) 

•  Computer  aided  design  drawing 

•  Post  layout  simulation 

•  Fabrication  methods 


2.  Adhere  to  applicable  standards  and  criteria. 

i  Examples  of  implementation  standards  include  the  following: 

i  •  Language  standards  (e.g.,  standards  for  software  programming  languages,  hardware 
;  description  languages) 

i  •  Drawing  requirements 
;  •  Standard  parts  lists 
;  •  Manufactured  parts 

;  •  Structure  and  hierarchy  of  software  product  components 
i  •  Process  and  quality  standards 


;  Examples  of  criteria  include  the  following: 
;  •  Modularity 

I  •  Clarity 

I  •  Simplicity 

I  •  Reliability 

I  •  Safety 

I  •  Maintainability 


3.  Conduct  peer  reviews  of  the  selected  product  components. 

Refer  to  the  Verification  process  area  for  more  information  about 
performing  peer  reviews. 

4.  Perform  unit  testing  of  the  product  component  as  appropriate. 

Note  that  unit  testing  is  not  limited  to  software.  Unit  testing  involves  the  testing  of 
individual  hardware  or  software  units  or  groups  of  related  items  prior  to  integration  of 
those  items. 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  seiected  work  products. 

;  Examples  of  unit  testing  methods  (manual  or  automated)  include  the  following: 

;  •  Statement  coverage  testing 
I  •  Branch  coverage  testing 
I  •  Predicate  coverage  testing 
I  •  Path  coverage  testing 
I  •  Boundary  value  testing 
I  •  Special  value  testing 
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I - - 

I  Examples  of  unit  testing  methods  include  the  following: 

I  •  Functional  testing 
I  •  Radiation  inspection  testing 
•  Environmental  testing 


5.  Revise  the  product  component  as  necessary. 

I  An  example  of  when  the  product  component  may  need  to  be  revised  is  when  problems 
i  surface  during  implementation  that  could  not  be  foreseen  during  design. 


SP  3.2  Develop  Product  Support  Documentation 

Develop  and  maintain  the  end-use  documentation. 

This  specific  practice  develops  and  maintains  the  documentation  that  will  be 
used  to  install,  operate,  and  maintain  the  product. 

Example  Work  Products 

1.  End-user  training  materials 

2.  User's  manual 

3.  Operator's  manual 

4.  Maintenance  manual 

5.  Online  help 
Subpractices 

1 .  Review  the  requirements,  design,  product,  and  test  results  to  ensure 
that  issues  affecting  the  installation,  operation,  and  maintenance 
documentation  are  identified  and  resolved. 

2.  Use  effective  methods  to  develop  the  installation,  operation,  and 
maintenance  documentation. 

3.  Adhere  to  the  applicable  documentation  standards. 

;  Examples  of  documentation  standards  include  the  following: 

I  •  Compatibility  with  designated  word  processors 
I  •  Acceptable  fonts 

I  •  Numbering  of  pages,  sections,  and  paragraphs 
I  •  Consistency  with  a  designated  style  manual 
I  •  Use  of  abbreviations 
I  •  Security  classification  markings 
•  Internationalization  requirements 

4.  Develop  preliminary  versions  of  the  installation,  operation,  and 
maintenance  documentation  in  early  phases  of  the  project  lifecycle  for 
review  by  the  relevant  stakeholders. 
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5.  Conduct  peer  reviews  of  the  installation,  operation,  and  maintenance 
documentation. 

Refer  to  the  Verification  process  area  for  more  information  about 
performing  peer  reviews. 

6.  Revise  the  installation,  operation,  and  maintenance  documentation  as 
necessary. 

^ - 

I  Examples  of  when  documentation  may  need  to  be  revised  include  when  the  following 

i  events  occur: 

I  •  Requirements  changes  are  made 
;  •  Design  changes  are  made 
;  •  Product  changes  are  made 
I  •  Documentation  errors  are  Identified 
i  •  Workaround  fixes  are  Identified 
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VALIDATION 


An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Validation  (VAL)  is  to  demonstrate  that  a  product  or  product 
component  fulfills  its  intended  use  when  placed  in  its  intended  environment. 


Introductory  Notes 


Validation  activities  can  be  applied  to  all  aspects  of  the  product  in  any  of  its 
intended  environments,  such  as  operation,  training,  manufacturing, 
maintenance,  and  support  services.  The  methods  employed  to  accomplish 
validation  can  be  applied  to  work  products  as  well  as  to  the  product  and 
product  components.  (Throughout  the  process  areas,  where  the  terms 
“product”  and  “product  component”  are  used,  their  intended  meanings  also 
encompass  services,  service  systems,  and  their  components.)  The  work 
products  (e.g.,  requirements,  designs,  prototypes)  should  be  selected  on 
the  basis  of  which  are  the  best  predictors  of  how  well  the  product  and 
product  component  will  satisfy  end  user  needs  and  thus  validation  is 
performed  early  (concept/exploration  phases)  and  incrementally  throughout 
the  product  lifecycle  (including  transition  to  operations  and  sustainment). 

The  validation  environment  should  represent  the  intended  environment  for 
the  product  and  product  components  as  well  as  represent  the  intended 
environment  suitable  for  validation  activities  with  work  products. 

Validation  demonstrates  that  the  product,  as  provided,  will  fulfill  its  intended 
use;  whereas,  verification  addresses  whether  the  work  product  properly 
reflects  the  specified  requirements.  In  other  words,  verification  ensures  that 
“you  built  it  right”;  whereas,  validation  ensures  that  “you  built  the  right  thing.” 
Validation  activities  use  approaches  similar  to  verification  (e.g.,  test, 
analysis,  inspection,  demonstration,  simulation).  Often,  the  end  users  and 
other  relevant  stakeholders  are  involved  in  the  validation  activities.  Both 
validation  and  verification  activities  often  run  concurrently  and  can  use 
portions  of  the  same  environment. 

Refer  to  the  Verification  process  area  for  more  information  about  ensuring 
that  seiected  work  products  meet  their  specified  requirements. 

Whenever  possible,  validation  should  be  accomplished  using  the  product  or 
product  component  operating  in  its  intended  environment.  The  entire 
environment  can  be  used  or  only  part  of  it.  However,  validation  issues  can 
be  discovered  early  in  the  life  of  the  project  using  work  products  by 
involving  relevant  stakeholders.  Validation  activities  for  services  can  be 
applied  to  work  products  such  as  proposals,  service  catalogs,  statements  of 
work,  and  service  records. 
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When  validation  issues  are  identified,  they  are  referred  to  processes 
associated  with  the  Requirements  Development,  Technical  Solution,  or 
Project  Monitoring  and  Control  process  areas  for  resolution. 

The  specific  practices  of  this  process  area  build  on  each  other  in  the 
following  way: 

•  The  Select  Products  for  Validation  specific  practice  enables  the 
identification  of  the  product  or  product  component  to  be  validated  and 
methods  to  be  used  to  perform  the  validation. 

•  The  Establish  the  Validation  Environment  specific  practice  enables  the 
determination  of  the  environment  to  be  used  to  carry  out  the  validation. 

•  The  Establish  Validation  Procedures  and  Criteria  specific  practice 
enables  the  development  of  validation  procedures  and  criteria  that  are 
aligned  with  the  characteristics  of  selected  products,  customer 
constraints  on  validation,  methods,  and  the  validation  environment. 

•  The  Perform  Validation  specific  practice  enables  the  performance  of 
validation  according  to  methods,  procedures,  and  criteria. 

Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more  information 
about  eliciting,  analyzing,  and  establishing  customer,  product,  and  product 
component  requirements. 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
selecting,  designing,  and  implementing  solutions  to  requirements. 

Refer  to  the  Verification  process  area  for  more  information  about  ensuring 
that  selected  work  products  meet  their  specified  requirements. 

Specific  Goal  and  Practice  Summary 

SG  1  Prepare  for  Validation 

SP  1 .1  Select  Products  for  Validation 
SP  1 .2  Establish  the  Validation  Environment 
SP  1 .3  Establish  Validation  Procedures  and  Criteria 

SG  2  Validate  Product  or  Product  Components 
SP  2.1  Perform  Validation 

SP  2.2  Analyze  Validation  Results 

Specific  Practices  by  Goal 


SG  1  Prepare  for  Validation 

Preparation  for  validation  is  conducted. 

Preparation  activities  include  selecting  products  and  product  components 
for  validation  and  establishing  and  maintaining  the  validation  environment, 
procedures,  and  criteria.  Items  selected  for  validation  can  include  only  the 
product  or  it  can  include  appropriate  levels  of  product  components  used  to 
build  the  product.  Any  product  or  product  component  can  be  subject  to 
validation,  including  replacement,  maintenance,  and  training  products,  to 
name  a  few. 
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The  environment  required  to  validate  the  product  or  product  component  is 
prepared.  The  environment  can  be  purchased  or  can  be  specified, 
designed,  and  built.  Environments  used  for  product  integration  and 
verification  can  be  considered  in  collaboration  with  the  validation 
environment  to  reduce  cost  and  improve  efficiency  or  productivity. 

SP  1 .1  Select  Products  for  Validation 

Select  products  and  product  components  to  be  validated  and 
validation  methods  to  be  used. 

Products  and  product  components  are  selected  for  validation  based  on  their 
relationship  to  end  user  needs.  For  each  product  component,  the  scope  of 
the  validation  (e.g.,  operational  behavior,  maintenance,  training,  user 
interface)  should  be  determined. 

I  Examples  of  products  and  product  components  that  can  be  validated  include  the  following: 

:  •  Product  and  product  component  requirements  and  designs 
I  •  Product  and  product  components  (e.g.,  system,  hardware  units,  software,  service 
i  documentation) 

;  •  User  interfaces 
i  •  User  manuals 
:  •  Training  materials 
I  •  Process  documentation 
;  •  Access  protocols 
i  •  Data  interchange  reporting  formats 


The  requirements  and  constraints  for  performing  validation  are  collected. 
Then,  validation  methods  are  selected  based  on  their  ability  to  demonstrate 
that  end  user  needs  are  satisfied.  The  validation  methods  not  only  define 
the  approach  to  product  validation,  but  also  drive  the  needs  for  the  facilities, 
equipment,  and  environments.  The  validation  approach  and  needs  can 
result  in  the  generation  of  lower  level  product  component  requirements  that 
are  handled  by  the  requirements  development  processes.  Derived 
requirements,  such  as  interface  requirements  to  test  sets  and  test 
equipment,  can  be  generated.  These  requirements  are  also  passed  to  the 
requirements  development  processes  to  ensure  that  the  product  or  product 
components  can  be  validated  in  an  environment  that  supports  the  methods. 

Validation  methods  should  be  selected  early  in  the  life  of  the  project  so  they 
are  clearly  understood  and  agreed  to  by  relevant  stakeholders. 

Validation  methods  address  the  development,  maintenance,  support,  and 
training  for  the  product  or  product  component  as  appropriate. 
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Examples  of  validation  methods  include  the  following: 

•  Discussions  with  end  users,  perhaps  in  the  context  of  a  formal  review 

•  Prototype  demonstrations 

•  Functional  demonstrations  (e.g.,  system,  hardware  units,  software,  service 
documentation,  user  interfaces) 

•  Pilots  of  training  materials 

•  Tests  of  products  and  product  components  by  end  users  and  other  relevant 
stakeholders 

•  Incremental  delivery  of  working  and  potentially  acceptable  product 

•  Analyses  of  product  and  product  components  (e.g.,  simulations,  modeling,  user 
analyses) 


f - - - - - - - - - - - - 

I  Hardware  validation  activities  include  modeling  to  validate  form,  fit,  and  function  of 
;  mechanical  designs;  thermal  modeling;  maintainability  and  reliability  analysis;  timeline 
I  demonstrations;  and  electrical  design  simulations  of  electronic  or  mechanical  product 
i  components. 


Example  Work  Products 

1 .  Lists  of  products  and  product  components  selected  for  validation 

2.  Validation  methods  for  each  product  or  product  component 

3.  Requirements  for  performing  validation  for  each  product  or  product 
component 

4.  Validation  constraints  for  each  product  or  product  component 
Subpractices 

1 .  Identify  the  key  principles,  features,  and  phases  for  product  or  product 
component  validation  throughout  the  life  of  the  project. 

2.  Determine  which  categories  of  end  user  needs  (operational, 
maintenance,  training,  or  support)  are  to  be  validated. 

The  product  or  product  component  should  be  maintainable  and  supportable  in  its 
intended  operational  environment.  This  specific  practice  also  addresses  the  actual 
maintenance,  training,  and  support  services  that  can  be  delivered  with  the  product. 

i  An  example  of  evaluation  of  maintenance  concepts  in  the  operational  environment  is  a 
;  demonstration  that  maintenance  tools  are  operating  with  the  actual  product. 


3.  Select  the  product  and  product  components  to  be  validated. 

4.  Select  the  evaluation  methods  for  product  or  product  component 
validation. 

5.  Review  the  validation  selection,  constraints,  and  methods  with  relevant 
stakeholders. 


396 


Validation  (VAL) 


CMMI  for  Development,  Version  1.3 


SP  1.2  Establish  the  Validation  Environment 

Establish  and  maintain  the  environment  needed  to  support 
validation. 

The  requirements  for  the  validation  environment  are  driven  by  the  product 
or  product  components  selected,  by  the  type  of  the  work  products  (e.g., 
design,  prototype,  final  version),  and  by  the  methods  of  validation.  These 
selections  can  yield  requirements  for  the  purchase  or  development  of 
equipment,  software,  or  other  resources.  These  requirements  are  provided 
to  the  requirements  development  processes  for  development.  The 
validation  environment  can  include  the  reuse  of  existing  resources.  In  this 
case,  arrangements  for  the  use  of  these  resources  should  be  made. 

:  Example  types  of  elements  In  a  validation  environment  Include  the  following: 

i  •  Test  tools  Interfaced  with  the  product  being  validated  (e.g.,  scope,  electronic  devices, 
i  probes) 

!•  Temporary  embedded  test  software 
I  •  Recording  tools  for  dump  or  further  analysis  and  replay 
;  •  Simulated  subsystems  or  components  (e.g.,  software,  electronics,  mechanics) 
i  •  Simulated  interfaced  systems  (e.g.,  a  dummy  warship  for  testing  a  naval  radar) 

;  •  Real  interfaced  systems  (e.g.,  aircraft  for  testing  a  radar  with  trajectory  tracking 

I  facilities) 

I  •  Facilities  and  customer  supplied  products 

;  •  Skilled  people  to  operate  or  use  all  the  preceding  elements 
i  •  Dedicated  computing  or  network  test  environment  (e.g.,  pseudo-operational 
I  telecommunications  network  test  bed  or  facility  with  actual  trunks,  switches,  and 
;  systems  established  for  realistic  integration  and  validation  trials) 


Early  selection  of  products  or  product  components  to  be  validated,  work 
products  to  be  used  in  validation,  and  validation  methods  is  needed  to 
ensure  that  the  validation  environment  will  be  available  when  necessary 

The  validation  environment  should  be  carefully  controlled  to  provide  for 
replication,  results  analysis,  and  revalidation  of  problem  areas. 

Example  Work  Products 

1.  Validation  environment 

Subpractices 

1 .  Identify  requirements  for  the  validation  environment. 

2.  Identify  customer  supplied  products. 

3.  Identify  test  equipment  and  tools. 

4.  Identify  validation  resources  that  are  available  for  reuse  and 
modification. 

5.  Plan  the  availability  of  resources  in  detail. 
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SP  1.3  Establish  Validation  Procedures  and  Criteria 

Establish  and  maintain  procedures  and  criteria  for  validation. 

Validation  procedures  and  criteria  are  defined  to  ensure  the  product  or 
product  component  will  fulfill  its  intended  use  when  placed  in  its  intended 
environment.  Test  cases  and  procedures  for  acceptance  testing  can  be 
used  for  validation  procedures. 

The  validation  procedures  and  criteria  include  test  and  evaluation  of 
maintenance,  training,  and  support  services. 

:  Examples  of  sources  for  validation  criteria  include  the  following: 
i  •  Product  and  product  component  requirements 
:  •  Standards 

I  •  Customer  acceptance  criteria 

;  •  Environmental  performance 

i  •  Thresholds  of  performance  deviation 


Example  Work  Products 

1 .  Validation  procedures 

2.  Validation  criteria 

3.  Test  and  evaluation  procedures  for  maintenance,  training,  and  support 
Subpractices 

1 .  Review  the  product  requirements  to  ensure  that  issues  affecting 
validation  of  the  product  or  product  component  are  identified  and 
resolved. 

2.  Document  the  environment,  operational  scenario,  procedures,  inputs, 
outputs,  and  criteria  for  the  validation  of  the  selected  product  or 
product  component. 

3.  Assess  the  design  as  it  matures  in  the  context  of  the  validation 
environment  to  identify  validation  issues. 

SG  2 _ Validate  Product  or  Product  Components _ 

The  product  or  product  components  are  validated  to  ensure  they  are  suitable 
for  use  in  their  intended  operating  environment. 

The  validation  methods,  procedures,  and  criteria  are  used  to  validate  the 
selected  products  and  product  components  and  any  associated 
maintenance,  training,  and  support  services  using  the  appropriate  validation 
environment.  Validation  activities  are  performed  throughout  the  product 
lifecycle. 

SP  2.1  Perform  Validation 

Perform  validation  on  selected  products  and  product  components. 

To  be  acceptable  to  stakeholders,  a  product  or  product  component  should 
perform  as  expected  in  its  intended  operational  environment. 
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Validation  activities  are  performed  and  the  resulting  data  are  collected 
according  to  established  methods,  procedures,  and  criteria. 

The  as-run  validation  procedures  should  be  documented  and  the  deviations 
occurring  during  the  execution  should  be  noted  as  appropriate. 

Example  Work  Products 

1 .  Validation  reports 

2.  Validation  results 

3.  Validation  cross  reference  matrix 

4.  As-run  procedures  log 

5.  Operational  demonstrations 

SP  2.2  Analyze  Validation  Results 

Analyze  results  of  validation  activities. 

The  data  resulting  from  validation  tests,  inspections,  demonstrations,  or 
evaluations  are  analyzed  against  defined  validation  criteria.  Analysis  reports 
indicate  whether  needs  were  met.  In  the  case  of  deficiencies,  these  reports 
document  the  degree  of  success  or  failure  and  categorize  probable  causes 
of  failure.  The  collected  test,  inspection,  or  review  results  are  compared 
with  established  evaluation  criteria  to  determine  whether  to  proceed  or  to 
address  requirements  or  design  issues  in  the  requirements  development  or 
technical  solution  processes. 

Analysis  reports  or  as-run  validation  documentation  can  also  indicate  that 
bad  test  results  are  due  to  a  validation  procedure  problem  or  a  validation 
environment  problem. 

Example  Work  Products 

1 .  Validation  deficiency  reports 

2.  Validation  issues 

3.  Procedure  change  request 
Subpractices 

1 .  Compare  actual  results  to  expected  results. 

2.  Based  on  the  established  validation  criteria,  identify  products  and 
product  components  that  do  not  perform  suitably  in  their  intended 
operating  environments,  or  identify  problems  with  methods,  criteria,  or 
the  environment. 

3.  Analyze  validation  data  for  defects. 

4.  Record  results  of  the  analysis  and  identify  issues. 

5.  Use  validation  results  to  compare  actual  measurements  and 
performance  to  the  intended  use  or  operational  need. 
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6.  Provide  information  on  how  defects  can  be  resolved  (including 
validation  methods,  criteria,  and  validation  environment)  and  initiate 
corrective  action. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  managing  corrective  actions. 
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VERIFICATION 


An  Engineering  Process  Area  at  Maturity  Level  3 


Purpose 


The  purpose  of  Verification  (VER)  is  to  ensure  that  selected  work  products 
meet  their  specified  requirements. 


Introductory  Notes 


The  Verification  process  area  involves  the  following:  verification 
preparation,  verification  performance,  and  identification  of  corrective  action. 

Verification  includes  verification  of  the  product  and  intermediate  work 
products  against  all  selected  requirements,  including  customer,  product, 
and  product  component  requirements.  For  product  lines,  core  assets  and 
their  associated  product  line  variation  mechanisms  should  also  be  verified. 
Throughout  the  process  areas,  where  the  terms  “product”  and  “product 
component”  are  used,  their  intended  meanings  also  encompass  services, 
service  systems,  and  their  components. 

Verification  is  inherently  an  incremental  process  because  it  occurs 
throughout  the  development  of  the  product  and  work  products,  beginning 
with  verification  of  requirements,  progressing  through  the  verification  of 
evolving  work  products,  and  culminating  in  the  verification  of  the  completed 
product. 

The  specific  practices  of  this  process  area  build  on  each  other  in  the 
following  way: 

•  The  Select  Work  Products  for  Verification  specific  practice  enables  the 
identification  of  work  products  to  be  verified,  methods  to  be  used  to 
perform  the  verification,  and  the  requirements  to  be  satisfied  by  each 
selected  work  product. 

•  The  Establish  the  Verification  Environment  specific  practice  enables  the 
determination  of  the  environment  to  be  used  to  carry  out  the  verification. 

•  The  Establish  Verification  Procedures  and  Criteria  specific  practice 
enables  the  development  of  verification  procedures  and  criteria  that  are 
aligned  with  selected  work  products,  requirements,  methods,  and 
characteristics  of  the  verification  environment. 

•  The  Perform  Verification  specific  practice  conducts  the  verification 
according  to  available  methods,  procedures,  and  criteria. 

Verification  of  work  products  substantially  increases  the  likelihood  that  the 
product  will  meet  the  customer,  product,  and  product  component 
requirements. 

The  Verification  and  Validation  process  areas  are  similar,  but  they  address 
different  issues.  Validation  demonstrates  that  the  product,  as  provided  (or 
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as  it  will  be  provided),  will  fulfill  its  intended  use,  whereas  verification 
addresses  whether  the  work  product  properly  reflects  the  specified 
requirements.  In  other  words,  verification  ensures  that  “you  built  it  right”; 
whereas,  validation  ensures  that  “you  built  the  right  thing.” 

Peer  reviews  are  an  important  part  of  verification  and  are  a  proven 
mechanism  for  effective  defect  removal.  An  important  corollary  is  to  develop 
a  better  understanding  of  the  work  products  and  the  processes  that 
produced  them  so  that  defects  can  be  prevented  and  process  improvement 
opportunities  can  be  identified. 

Peer  reviews  involve  a  methodical  examination  of  work  products  by  the 
producers’  peers  to  identify  defects  and  other  changes  that  are  needed. 

Examples  of  peer  review  methods  include  the  following: 

•  Inspections 

•  Structured  walkthroughs 

•  Deliberate  refactoring 

•  Pair  programming 


In  Agile  environments,  because  of  customer  involvement  and  frequent  releases,  verification 
and  validation  mutually  support  each  other.  For  example,  a  defect  can  cause  a  prototype  or 
early  release  to  fail  validation  prematurely.  Conversely,  early  and  continuous  validation  helps 
ensure  verification  is  applied  to  the  right  product.  The  Verification  and  Validation  process 
areas  help  ensure  a  systematic  approach  to  selecting  the  work  products  to  be  reviewed  and 
tested,  the  methods  and  environments  to  be  used,  and  the  interfaces  to  be  managed,  which 
help  ensure  that  defects  are  identified  and  addressed  early.  The  more  complex  the  product, 
the  more  systematic  the  approach  needs  to  be  to  ensure  compatibility  among  requirements 
and  solutions,  and  consistency  with  how  the  product  will  be  used.  (See  “Interpreting  CMMI 
When  Using  Agile  Approaches”  in  Part  I.) 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more  information 
about  eliciting,  analyzing,  and  establishing  customer,  product,  and  product 
component  requirements. 

Refer  to  the  Validation  process  area  for  more  information  about 
demonstrating  that  a  product  or  product  component  fulfills  its  intended  use 
when  placed  in  its  intended  environment. 

Refer  to  the  Requirements  Management  process  area  for  more  information 
about  ensuring  alignment  between  project  work  and  requirements. 
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Specific  Goai  and  Practice  Summary 

SG  1  Prepare  for  Verification 

SP  1 .1  Seiect  Work  Products  for  Verification 
SP  1 .2  Estabiish  the  Verification  Environment 
SP  1 .3  Estabiish  Verification  Procedures  and  Criteria 
SG  2  Perform  Peer  Reviews 

SP2.1  Prepare  for  Peer  Reviews 
SP  2.2  Conduct  Peer  Reviews 

SP  2.3  Analyze  Peer  Review  Data 

SG  3  Verify  Seiected  Work  Products 
SP  3.1  Perform  Verification 

SP  3.2  Analyze  Verification  Results 

Specific  Practices  by  Goai 


SG  1  Prepare  for  Verification 

Preparation  for  verification  is  conducted. 

Up-front  preparation  is  necessary  to  ensure  that  verification  provisions  are 
embedded  in  product  and  product  component  requirements,  designs, 
developmental  plans,  and  schedules.  Verification  includes  the  selection, 
inspection,  testing,  analysis,  and  demonstration  of  work  products. 

Methods  of  verification  include,  but  are  not  limited  to,  inspections,  peer 
reviews,  audits,  walkthroughs,  analyses,  architecture  evaluations, 
simulations,  testing,  and  demonstrations.  Practices  related  to  peer  reviews 
as  a  specific  verification  method  are  included  in  specific  goal  2. 

Preparation  also  entails  the  definition  of  support  tools,  test  equipment  and 
software,  simulations,  prototypes,  and  facilities. 

SP  1 .1  Select  Work  Products  for  Verification 

Seiect  work  products  to  be  verified  and  verification  methods  to  be 
used. 

Work  products  are  selected  based  on  their  contribution  to  meeting  project 
objectives  and  requirements,  and  to  addressing  project  risks. 

The  work  products  to  be  verified  can  include  the  ones  associated  with 
maintenance,  training,  and  support  services.  The  work  product 
requirements  for  verification  are  included  with  the  verification  methods.  The 
verification  methods  address  the  approach  to  work  product  verification  and 
the  specific  approaches  that  will  be  used  to  verify  that  specific  work 
products  meet  their  requirements. 
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Examples  of  verification  methods  include  the  following: 

•  Software  architecture  evaluation  and  implementation  conformance  evaluation 

•  Path  coverage  testing 

•  Load,  stress,  and  performance  testing 

•  Decision  table  based  testing 

•  Functional  decomposition  based  testing 

•  Test  case  reuse 

•  Acceptance  testing 

•  Continuous  integration  (i.e.,  Agile  approach  that  identifies  integration  issues  early) 


I  Verification  for  systems  engineering  typically  includes  prototyping,  modeling,  and  simulation 
;  to  verify  adequacy  of  system  design  (and  allocation). 


Verification  for  hardware  engineering  typically  requires  a  parametric  approach  that  considers 
various  environmental  conditions  (e.g.,  pressure,  temperature,  vibration,  humidity),  various 
input  ranges  (e.g.,  input  power  could  be  rated  at  20V  to  32V  for  a  planned  nominal  of  28V), 
variations  induced  from  part  to  part  tolerance  issues,  and  many  other  variables.  Hardware 
verification  normally  tests  most  variables  separately  except  when  problematic  interactions 
are  suspected. 


Selection  of  verification  methods  typically  begins  with  the  definition  of 
product  and  product  component  requirements  to  ensure  that  the 
requirements  are  verifiable.  Re-verification  should  be  addressed  by 
verification  methods  to  ensure  that  rework  performed  on  work  products 
does  not  cause  unintended  defects.  Suppliers  should  be  involved  in  this 
selection  to  ensure  that  the  project's  methods  are  appropriate  for  the 
supplier's  environment. 

Example  Work  Products 

1 .  Lists  of  work  products  selected  for  verification 

2.  Verification  methods  for  each  selected  work  product 
Subpractices 

1 .  Identify  work  products  for  verification. 

2.  Identify  requirements  to  be  satisfied  by  each  selected  work  product. 

Refer  to  the  Maintain  Bidirectionai  Traceabiiity  of  Requirements 
specific  practice  in  the  Requirements  Management  process  area  for 
more  information  about  tracing  requirements  to  work  products. 

3.  Identify  verification  methods  available  for  use. 

4.  Define  verification  methods  to  be  used  for  each  selected  work  product. 

5.  Submit  for  integration  with  the  project  plan  the  identification  of  work 
products  to  be  verified,  the  requirements  to  be  satisfied,  and  the 
methods  to  be  used. 
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Refer  to  the  Project  Planning  process  area  for  more  information  about 
developing  the  project  plan. 

SP  1.2  Establish  the  Verification  Environment 

Establish  and  maintain  the  environment  needed  to  support 
verification. 

An  environment  should  be  established  to  enable  verification  to  take  place. 
The  verification  environment  can  be  acquired,  developed,  reused,  modified, 
or  obtained  using  a  combination  of  these  activities,  depending  on  the  needs 
of  the  project. 

The  type  of  environment  required  depends  on  the  work  products  selected 
for  verification  and  the  verification  methods  used.  A  peer  review  can  require 
little  more  than  a  package  of  materials,  reviewers,  and  a  room.  A  product 
test  can  require  simulators,  emulators,  scenario  generators,  data  reduction 
tools,  environmental  controls,  and  interfaces  with  other  systems. 

Example  Work  Products 

1.  Verification  environment 

Subpractices 

1 .  Identify  verification  environment  requirements. 

2.  Identify  verification  resources  that  are  available  for  reuse  or 
modification. 

3.  Identify  verification  equipment  and  tools. 

4.  Acquire  verification  support  equipment  and  an  environment  (e.g.,  test 
equipment,  software). 

SP  1.3  Establish  Verification  Procedures  and  Criteria 

Establish  and  maintain  verification  procedures  and  criteria  for  the 
selected  work  products. 

Verification  criteria  are  defined  to  ensure  that  work  products  meet  their 
requirements. 

f................ - - - - 

I  Examples  of  sources  for  verification  criteria  include  the  following: 

I  •  Product  and  product  component  requirements 
;  •  Standards 
i  •  Organizational  policies 
;  •  Test  type 
i  •  Test  parameters 

:  •  Parameters  for  tradeoff  between  quality  and  cost  of  testing 
•  Type  of  work  products 
;  •  Suppliers 

i  •  Proposals  and  agreements 

;  •  Customers  reviewing  work  products  collaboratively  with  developers 
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Example  Work  Products 

1 .  Verification  procedures 

2.  Verification  criteria 
Subpractices 

1 .  Generate  a  set  of  comprehensive,  integrated  verification  procedures 
for  work  products  and  commercial  off-the-shelf  products,  as  necessary. 

2.  Develop  and  refine  verification  criteria  as  necessary. 

3.  Identify  the  expected  results,  tolerances  allowed,  and  other  criteria  for 
satisfying  the  requirements. 

4.  Identify  equipment  and  environmental  components  needed  to  support 
verification. 

SG  2  Perform  Peer  Reviews 

Peer  reviews  are  performed  on  selected  work  products. 

Peer  reviews  involve  a  methodical  examination  of  work  products  by  the 
producers’  peers  to  identify  defects  for  removal  and  to  recommend  other 
changes  that  are  needed. 

The  peer  review  is  an  important  and  effective  verification  method 
implemented  via  inspections,  structured  walkthroughs,  or  a  number  of  other 
collegial  review  methods. 

Peer  reviews  are  primarily  applied  to  work  products  developed  by  the 
projects,  but  they  can  also  be  applied  to  other  work  products  such  as 
documentation  and  training  work  products  that  are  typically  developed  by 
support  groups. 

SP  2.1  Prepare  for  Peer  Reviews 

Prepare  for  peer  reviews  of  selected  work  products. 

Preparation  activities  for  peer  reviews  typically  include  identifying  the  staff 
to  be  invited  to  participate  in  the  peer  review  of  each  work  product; 
identifying  key  reviewers  who  should  participate  in  the  peer  review; 
preparing  and  updating  materials  to  be  used  during  peer  reviews,  such  as 
checklists  and  review  criteria  and  scheduling  peer  reviews. 

Example  Work  Products 

1 .  Peer  review  schedule 

2.  Peer  review  checklist 

3.  Entry  and  exit  criteria  for  work  products 

4.  Criteria  for  requiring  another  peer  review 

5.  Peer  review  training  material 

6.  Selected  work  products  to  be  reviewed 
Subpractices 

1 .  Determine  the  type  of  peer  review  to  be  conducted. 
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Examples  of  types  of  peer  reviews  include  the  following: 

•  Inspections 

•  Structured  walkthroughs 

•  Active  reviews 

•  Architecture  implementation  conformance  evaluation 


2.  Define  requirements  for  collecting  data  during  the  peer  review. 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  obtaining  measurement  data. 

3.  Establish  and  maintain  entry  and  exit  criteria  for  the  peer  review. 

4.  Establish  and  maintain  criteria  for  requiring  another  peer  review. 

5.  Establish  and  maintain  checklists  to  ensure  that  work  products  are 
reviewed  consistently. 

;  Examples  of  items  addressed  by  the  checklists  include  the  following: 

I  •  Rules  of  construction 
;  •  Design  guidelines 
I  •  Completeness 
I  •  Correctness 
I  •  Maintainability 
I  •  Common  defect  types 

The  checklists  are  modified  as  necessary  to  address  the  specific  type  of  work  product 
and  peer  review.  The  peers  of  the  checklist  developers  and  potential  end-users  review 
the  checklists. 

6.  Develop  a  detailed  peer  review  schedule,  including  the  dates  for  peer 
review  training  and  for  when  materials  for  peer  reviews  will  be 
available. 

7.  Ensure  that  the  work  product  satisfies  the  peer  review  entry  criteria 
prior  to  distribution. 

8.  Distribute  the  work  product  to  be  reviewed  and  related  information  to 
participants  early  enough  to  enable  them  to  adequately  prepare  for  the 
peer  review. 

9.  Assign  roles  for  the  peer  review  as  appropriate. 

;  Examples  of  roles  include  the  following: 

;  •  Leader 
;  •  Reader 
I  •  Recorder 
!  •  Author 


1 0.  Prepare  for  the  peer  review  by  reviewing  the  work  product  prior  to 
conducting  the  peer  review. 
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SP  2.2  Conduct  Peer  Reviews 

Conduct  peer  reviews  of  selected  work  products  and  identify 
issues  resulting  from  these  reviews. 

One  of  the  purposes  of  conducting  a  peer  review  is  to  find  and  remove 
defects  early.  Peer  reviews  are  performed  incrementally  as  work  products 
are  being  developed.  These  reviews  are  structured  and  are  not 
management  reviews. 

Peer  reviews  can  be  performed  on  key  work  products  of  specification, 
design,  test,  and  implementation  activities  and  specific  planning  work 
products. 

The  focus  of  the  peer  review  should  be  on  the  work  product  in  review,  not 
on  the  person  who  produced  it. 

When  issues  arise  during  the  peer  review,  they  should  be  communicated  to 
the  primary  developer  of  the  work  product  for  correction. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  monitoring  the  project  against  the  pian. 

Peer  reviews  should  address  the  following  guidelines:  there  should  be 
sufficient  preparation,  the  conduct  should  be  managed  and  controlled, 
consistent  and  sufficient  data  should  be  recorded  (an  example  is 
conducting  a  formal  inspection),  and  action  items  should  be  recorded. 

Example  Work  Products 

1.  Peer  review  results 

2.  Peer  review  issues 

3.  Peer  review  data 

Subpractices 

1 .  Perform  the  assigned  roles  in  the  peer  review. 

2.  Identify  and  document  defects  and  other  issues  in  the  work  product. 

3.  Record  results  of  the  peer  review,  including  action  items. 

4.  Collect  peer  review  data. 

Refer  to  the  Measurement  and  Anaiysis  process  area  for  more 
information  about  obtaining  measurement  data. 

5.  Identify  action  items  and  communicate  issues  to  relevant  stakeholders. 

6.  Conduct  an  additional  peer  review  if  needed. 

7.  Ensure  that  the  exit  criteria  for  the  peer  review  are  satisfied. 

SP  2.3  Analyze  Peer  Review  Data 

Analyze  data  about  the  preparation,  conduct,  and  results  of  the 
peer  reviews. 

Refer  to  the  Measurement  and  Anaiysis  process  area  for  more  information 
about  obtaining  measurement  data  and  anaiyzing  measurement  data. 

Example  Work  Products 

1 .  Peer  review  data 
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2.  Peer  review  action  items 

Subpractices 

1 .  Record  data  related  to  the  preparation,  conduct,  and  results  of  the  peer 
reviews. 

Typical  data  are  product  name,  product  size,  composition  of  the  peer  review  team, 
type  of  peer  review,  preparation  time  per  reviewer,  length  of  the  review  meeting, 
number  of  defects  found,  type  and  origin  of  defect,  and  so  on.  Additional  information 
on  the  work  product  being  peer  reviewed  can  be  collected,  such  as  size,  development 
stage,  operating  modes  examined,  and  requirements  being  evaluated. 

2.  Store  the  data  for  future  reference  and  analysis. 

3.  Protect  the  data  to  ensure  that  peer  review  data  are  not  used 
inappropriately. 

;  Examples  of  the  inappropriate  use  of  peer  review  data  include  using  data  to  evaluate 
I  the  performance  of  people  and  using  data  for  attribution. 


4.  Analyze  the  peer  review  data. 

I  Examples  of  peer  review  data  that  can  be  analyzed  include  the  following: 

:  •  Phase  defect  was  injected 

I  •  Preparation  time  or  rate  versus  expected  time  or  rate 

i  •  Number  of  defects  versus  number  expected 

i  •  Types  of  defects  detected 

i  •  Causes  of  defects 

i  •  Defect  resolution  impact 

;  •  User  stories  or  case  studies  associated  with  a  defect 

;  •  The  end  users  and  customers  who  are  associated  with  defects 


SG  3 _ Verify  Selected  Work  Products _ 

Selected  work  products  are  verified  against  their  specified  requirements. 

Verification  methods,  procedures,  and  criteria  are  used  to  verify  selected 
work  products  and  associated  maintenance,  training,  and  support  services 
using  the  appropriate  verification  environment.  Verification  activities  should 
be  performed  throughout  the  product  lifecycle.  Practices  related  to  peer 
reviews  as  a  specific  verification  method  are  included  in  specific  goal  2. 

SP  3.1  Perform  Verification 

Perform  verification  on  selected  work  products. 

Verifying  products  and  work  products  incrementally  promotes  early 
detection  of  problems  and  can  result  in  the  early  removal  of  defects.  The 
results  of  verification  save  the  considerable  cost  of  fault  isolation  and 
rework  associated  with  troubleshooting  problems. 
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Example  Work  Products 

1 .  Verification  results 

2.  Verification  reports 

3.  Demonstrations 

4.  As-run  procedures  log 
Subpractices 

1 .  Perform  the  verification  of  selected  work  products  against  their 
requirements. 

2.  Record  the  results  of  verification  activities. 

3.  Identify  action  items  resulting  from  the  verification  of  work  products. 

4.  Document  the  “as-run”  verification  method  and  deviations  from 
available  methods  and  procedures  discovered  during  its  performance. 

SP  3.2  Analyze  Verification  Results 

Analyze  results  of  all  verification  activities. 

Actual  results  should  be  compared  to  established  verification  criteria  to 
determine  acceptability. 

The  results  of  the  analysis  are  recorded  as  evidence  that  verification  was 
conducted. 

For  each  work  product,  all  available  verification  results  are  incrementally 
analyzed  to  ensure  that  requirements  have  been  met.  Since  a  peer  review 
is  one  of  several  verification  methods,  peer  review  data  should  be  included 
in  this  analysis  activity  to  ensure  that  verification  results  are  analyzed 
sufficiently. 

Analysis  reports  or  “as-run”  method  documentation  can  also  indicate  that 
bad  verification  results  are  due  to  method  problems,  criteria  problems,  or  a 
verification  environment  problem. 

Example  Work  Products 

1 .  Analysis  report  (e.g.,  statistics  on  performance,  causal  analysis  of 
nonconformances,  comparison  of  the  behavior  between  the  real 
product  and  models,  trends) 

2.  Trouble  reports 

3.  Change  requests  for  verification  methods,  criteria,  and  the  environment 

Subpractices 

1 .  Compare  actual  results  to  expected  results. 

2.  Based  on  the  established  verification  criteria,  identify  products  that  do 
not  meet  their  requirements  or  identify  problems  with  methods, 
procedures,  criteria,  and  the  verification  environment. 

3.  Analyze  defect  data. 

4.  Record  all  results  of  the  analysis  in  a  report. 
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5.  Use  verification  results  to  compare  actual  measurements  and 
performance  to  technical  performance  parameters. 

6.  Provide  information  on  how  defects  can  be  resolved  (including 
verification  methods,  criteria,  and  verification  environment)  and  initiate 
corrective  action. 

Refer  to  the  Project  Monitoring  and  Controi  process  area  for  more 
information  about  taking  corrective  action. 
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Appendix  B:  Acronyms 


ANSI 

American  National  Standards  Institute 

API 

application  program  interface 

ARC 

Appraisal  Requirements  for  CMMI 

CAD 

computer-aided  design 

CAR 

Causal  Analysis  and  Resolution  (process  area) 

CCB 

configuration  control  board 

CL 

capability  level 

CM 

Configuration  Management  (process  area) 

CMU 

Carnegie  Mellon  University 

CMF 

CMMI  Model  Foundation 

CMM 

Capability  Maturity  Model 

CMMI 

Capability  Maturity  Model  Integration 

CMMI-ACQ 

CMMI  for  Acquisition 

CMMI-DEV 

CMMI  for  Development 

CMMI-SVC 

CMMI  for  Services 

CobiT 

Control  Objectives  for  Information  and  related  Technology 

COTS 

commercial  off-the-shelf 

CPI 

cost  performance  index 

CPM 

critical  path  method 

CSCI 

computer  software  configuration  item 

DAR 

Decision  Analysis  and  Resolution  (process  area) 

Acronyms 
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DHS 

DoD 

EIA 

EIA/IS 

FCA 

FMEA 

GG 

GP 

IBM 

IDEAL 

IEEE 

INCOSE 

IPD-CMM 

IPM 

ISO 

ISO/I  EC 

ITIL 

MA 

MDD 

ML 

NDIA 

OID 

OPD 

OPF 


Department  of  Homeland  Security 

Department  of  Defense 

Electronic  Industries  Alliance 

Electronic  Industries  Alliance/Interim  Standard 

functional  configuration  audit 

failure  mode  and  effects  analysis 

generic  goal 

generic  practice 

International  Business  Machines 

Initiating,  Diagnosing,  Establishing,  Acting,  Learning 

Institute  of  Electrical  and  Electronics  Engineers 

International  Council  on  Systems  Engineering 

Integrated  Product  Development  Capability  Maturity  Model 

Integrated  Project  Management  (process  area) 

International  Organization  for  Standardization 

International  Organization  for  Standardization  and 
International  Electrotechnical  Commission 

Information  Technology  Infrastructure  Library 

Measurement  and  Analysis  (process  area) 

Method  Definition  Document 

maturity  level 

National  Defense  Industrial  Association 

Organizational  Innovation  and  Deployment  (former  process 
area) 

Organizational  Process  Definition  (process  area) 
Organizational  Process  Focus  (process  area) 
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0PM 

OPP 

OT 

P-CMM 

PCA 

PERT 

PI 

PMC 

PP 

PPQA 

QFD 

QPM 

RD 

REQM 

RSKM 

SA-CMM 

SAM 

SCAMPI 

SECAM 

SECM 

SEI 

SG 

SP 

SPI 

SSD 


Organizational  Performance  Management  (process  area) 
Organizational  Process  Performance  (process  area) 
Organizational  Training  (process  area) 

People  Capability  Maturity  Model 
physical  configuration  audit 
Program  Evaluation  and  Review  Technique 
Product  Integration  (process  area) 

Project  Monitoring  and  Control  (process  area) 

Project  Planning  (process  area) 

Process  and  Product  Ouality  Assurance  (process  area) 
Ouality  Function  Deployment 
Ouantitative  Project  Management  (process  area) 
Requirements  Development  (process  area) 

Requirements  Management  (process  area) 

Risk  Management  (process  area) 

Software  Acquisition  Capability  Maturity  Model 
Supplier  Agreement  Management  (process  area) 

Standard  CMMI  Appraisal  Method  for  Process  Improvement 

Systems  Engineering  Capability  Assessment  Model 

Systems  Engineering  Capability  Model 

Software  Engineering  Institute 

specific  goal 

specific  practice 

schedule  performance  index 

Service  System  Development  (process  area  in  CMMI-SVC) 


Acronyms 
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SSE-CMM 

Systems  Security  Engineering  Capability  Maturity  Model 

SW-CMM 

Capability  Maturity  Model  for  Software  or  Software 
Capability  Maturity  Model 

TS 

Technical  Solution  (process  area) 

VAL 

Validation  (process  area) 

VER 

Verification  (process  area) 

WBS 

work  breakdown  structure 
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Appendix  C:  CMMI  Version  1.3  Project 
Participants 


Many  talented  people  were  part  of  the  product  team  that  developed  CMMI 
Version  1 .3  models.  Listed  below  are  those  who  participated  in  one  or  more 
of  the  following  teams  during  the  development  of  CMMI  Version  1 .3.  The 
organizations  listed  by  members’  names  are  those  they  represented  at  the 
time  of  their  team  membership. 

The  following  are  the  primary  groups  involved  in  the  development  of  this 
model: 

•  CMMI  Steering  Group 

•  CMMI  for  Services  Advisory  Group 

•  CMMI  V1 .3  Coordination  Team 

•  CMMI  V1 .3  Configuration  Control  Board 

•  CMMI  V1 .3  Core  Model  Team 

•  CMMI  V1 .3  Translation  Team 

•  CMMI  V1 .3  High  Maturity  Team 

•  CMMI  V1 .3  Acquisition  Mini  Team 

•  CMMI  V1 .3  Services  Mini  Team 

•  CMMI  V1 .3  SCAMPI  Upgrade  Team 

•  CMMI  V1 .3  Training  Teams 

•  CMMI  V1 .3  Quality  Team 


CMMI  Steering  Group 

The  CMMI  Steering  Group  guides  and  approves  the  plans  of  the  CMMI 
Product  Team,  provides  consultation  on  significant  CMMI  project  issues, 
ensures  involvement  from  a  variety  of  interested  communities,  and 
approves  the  final  release  of  the  model. 

Steering  Group  Members _ 

•  Alan  Bemish,  US  Air  Force 

•  Anita  Carleton,  Software  Engineering  Institute 

•  Clyde  Chittister,  Software  Engineering  Institute 

•  James  Gill,  Boeing  Integrated  Defense  Systems 

•  John  C.  Kelly,  NASA 

•  Kathryn  Lundeen,  Defense  Contract  Management  Agency 
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•  Larry  McCarthy,  Motorola,  Inc. 

•  Lawrence  Osiecki,  US  Army 

•  Robert  Rassa,  Raytheon  Space  and  Airborne  Systems  (lead) 

•  Karen  Richter,  Institute  for  Defense  Analyses 

•  Joan  Weszka,  Lockheed  Martin  Corporation 

•  Harold  Wilson,  Northrop  Grumman 

•  Brenda  Zettervall,  US  Navy 

Ex-Officio  Steering  Group  Members 

•  Mike  Konrad,  Software  Engineering  Institute 

•  Susan  LaFortune,  National  Security  Agency 

•  David  (Mike)  Phillips,  Software  Engineering  Institute 

Steering  Group  Support _ 

•  Mary  Beth  Chrissis,  Software  Engineering  Institute  (CCB) 

•  Eric  Hayes,  Software  Engineering  Institute  (secretary) 

•  Rawdon  Young,  Software  Engineering  Institute  (Appraisal  program) 


CMMI  for  Services  Advisory  Group 

The  Services  Advisory  Group  provides  advice  to  the  product  development 
team  about  service  industries. 

•  Brandon  Buteau,  Northrop  Grumman  Corporation 

•  Christian  Carmody,  University  of  Pittsburgh  Medical  Center 

•  Sandra  Cepeda,  Cepeda  Systems  &  Software  Analysis/RDECOM  SED 

•  Annie  Combelles,  DNV  IT  Global  Services 

•  Jeff  Dutton,  Jacobs  Technology,  Inc. 

•  Eileen  Forrester,  Software  Engineering  Institute 

•  Craig  Hollenbach,  Northrop  Grumman  Corporation  (lead) 

•  Bradley  Nelson,  Department  of  Defense 

•  Lawrence  Osiecki,  US  Army  ARDEC 

•  David  (Mike)  Phillips,  Software  Engineering  Institute 

•  Timothy  Salerno,  Lockheed  Martin  Corporation 

•  Sandy  Shrum,  Software  Engineering  Institute 

•  Nidhi  Srivastava,  Tata  Consultancy  Services 

•  Elizabeth  Sumpter,  NSA 

•  David  Swidorsky,  Bank  of  America 
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CMMI  V1.3  Coordination  Team 

The  Coordination  team  brings  together  members  of  other  product 
development  teams  to  ensure  coordination  across  the  project. 

•  Rhonda  Brown,  Software  Engineering  Institute 

•  Mary  Beth  Chrissis,  Software  Engineering  Institute 

•  Eileen  Forrester,  Software  Engineering  Institute 

•  Will  Hayes,  Software  Engineering  Institute 

•  Mike  Konrad,  Software  Engineering  Institute 

•  So  Norimatsu,  Norimatsu  Process  Engineering  Lab,  Inc. 

•  Mary  Lynn  Penn,  Lockheed  Martin  Corporation 

•  David  (Mike)  Phillips,  Software  Engineering  Institute  (lead) 

•  Sandy  Shrum,  Software  Engineering  Institute 

•  Kathy  Smith,  Hewlett  Packard 

•  Barbara  Tyson,  Software  Engineering  Institute 

•  Rawdon  Young,  Software  Engineering  Institute 

•  Mary  Lynn  Russo,  Software  Engineering  Institute  (non-voting  member) 


CMMI  V1.3  Configuration  Controi  Board 

The  Configuration  Control  Board  approves  all  changes  to  CMMI  materials, 
including  the  models,  the  SCAMPI  MDD,  and  introductory  model  training. 

•  Rhonda  Brown,  Software  Engineering  Institute 

•  Michael  Campo,  Raytheon 

•  Mary  Beth  Chrissis,  Software  Engineering  Institute  (lead) 

•  Kirsten  Dauplaise,  NAVAIR 

•  Mike  Evanoo,  Systems  and  Software  Consortium,  Inc. 

•  Rich  Frost,  General  Motors 

•  Brian  Gallagher,  Northrop  Grumman 

•  Sally  Godfrey,  NASA 

•  Stephen  Gristock,  JP  Morgan  Chase  and  Co. 

•  Eric  Hayes  (non-voting  member) 

•  Nils  Jacobsen,  Motorola 

•  Steve  Kapurch,  NASA 

•  Mike  Konrad,  Software  Engineering  Institute 

•  Chris  Moore,  US  Air  Force 

•  Wendell  Mullison,  General  Dynamics  Land  Systems 

•  David  (Mike)  Phillips,  Software  Engineering  Institute 

•  Robert  Rassa,  Raytheon  Space  and  Airborne  Systems 

•  Karen  Richter,  Institute  for  Defense  Analyses 

•  Mary  Lou  Russo  (non-voting  member) 
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•  Warren  Schwoemeyer,  Lockheed  Martin  Corporation 

•  John  Scibiiia,  US  Army 

•  Dave  Swidorsky,  Bank  of  America 

•  Barbara  Tyson,  Software  Engineering  institute 

•  Mary  Van  Tyne,  Software  Engineering  institute  (non-voting  member) 

•  Rawdon  Young,  Software  Engineering  Institute 


CMMI  V1.3  Core  Model  Team _ 

The  Core  Model  Team  develops  the  model  material  for  all  three 
constellations. 

•  Jim  Armstrong,  Stevens  Institute  of  Technology 

•  Rhonda  Brown,  Software  Engineering  Institute  (co-lead) 

•  Brandon  Buteau,  Northrop  Grumman 

•  Michael  Campo,  Raytheon 

•  Sandra  Cepeda,  Cepeda  Systems  &  Software  Analysis/RDECOM  SED 

•  Mary  Beth  Chrissis,  Software  Engineering  Institute 

•  Mike  D’Ambrosa,  Process  Performance  Professionals 

•  Eileen  Forrester,  Software  Engineering  Institute 

•  Will  Hayes,  Software  Engineering  Institute 

•  Mike  Konrad,  Software  Engineering  Institute  (co-lead) 

•  So  Norimatsu,  Norimatsu  Process  Engineering  Lab,  Inc. 

•  Mary  Lynn  Penn,  Lockheed  Martin  Corporation 

•  David  (Mike)  Phillips,  Software  Engineering  Institute 

•  Karen  Richter,  Institute  for  Defense  Analyses 

•  Mary  Lynn  Russo,  Software  Engineering  Institute  (non-voting  member) 

•  John  Scibiiia,  US  Army 

•  Sandy  Shrum,  Software  Engineering  Institute  (co-lead) 

•  Kathy  Smith,  Hewlett  Packard 

•  Katie  Smith-McGarty,  US  Navy 


CMMI  V1.3  Translation  Team 

The  Translation  Team  coordinates  translation  work  on  CMMI  materials. 

•  Richard  Basque,  Alcyonix 

•  Jose  Antonio  Calvo-Manzano,  Universidad  Politecnica  de  Madrid 

•  Carlos  Caram,  Integrated  Systems  Diagnostics  Brazil 

•  Gonzalo  Cuevas,  Universidad  Politecnica  de  Madrid 

•  Mike  Konrad,  Software  Engineering  Institute 

•  Antoine  Nardeze,  Alcyonix 
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•  So  Norimatsu,  Norimatsu  Process  Engineering  Lab,  Inc.  (lead) 

•  Seven  Ou,  Institute  for  Information  Industry 

•  Ricardo  Panero  Lamothe,  Accenture 

•  Mary  Lynn  Russo,  Software  Engineering  Institute  (non-voting  member) 

•  Winfried  Russwurm,  Siemens  AG 

•  Tomas  San  Feliu,  Universidad  Politecnica  de  Madrid 


CMMI  V1.3  High  Maturity  Team _ 

The  High  Maturity  team  developed  high  maturity  model  material. 

•  Dan  Bennett,  US  Air  Force 

•  Will  Hayes,  Software  Engineering  Institute 

•  Rick  Hefner,  Northrop  Grumman 

•  Jim  Kubeck,  Lockheed  Martin  Corporation 

•  Alice  Parry,  Raytheon 

•  Mary  Lynn  Penn,  Lockheed  Martin  Corporation  (lead) 

•  Kathy  Smith,  Hewlett  Packard 

•  Rawdon  Young,  Software  Engineering  Institute 


CMMI  V1.3  Acquisition  Mini  Team _ 

The  Acquisition  Mini  Team  provides  acquisition  expertise  for  model 
development  work. 

•  Rich  Frost,  General  Motors 

•  Tom  Keuten,  Keuten  and  Associates 

•  David  (Mike)  Phillips,  Software  Engineering  Institute  (lead) 

•  Karen  Richter,  Institute  for  Defense  Analyses 

•  John  Scibilia,  US  Army 


CMMI  V1.3  Services  Mini  Team _ 

The  Services  Mini  Team  provides  service  expertise  for  model  development 
work. 

•  Drew  Allison,  Systems  and  Software  Consortium,  Inc. 

•  Brandon  Buteau,  Northrop  Grumman 

•  Eileen  Forrester,  Software  Engineering  Institute  (lead) 

•  Christian  Hertneck,  Anywhere. 24  GmbH 

•  Pam  Schoppert,  Science  Applications  International  Corporation 
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CMMI  V1.3  SCAMPI  Upgrade  Team _ 

The  SCAMPI  Upgrade  team  develops  the  Appraisal  Requirements  for 
CMMI  (ARC)  document  and  SCAMPI  Method  Definition  Document  (MDD). 

•  Mary  Busby,  Lockheed  Martin  Corporation 

•  Palma  Buttles-Valdez,  Software  Engineering  Institute 

•  Paul  Byrnes,  Integrated  System  Diagnostics 

•  Will  Hayes,  Software  Engineering  Institute  (leader) 

•  Ravi  Khetan,  Northrop  Grumman 

•  Denise  Kirkham,  The  Boeing  Company 

•  Lisa  Ming,  The  Boeing  Company 

•  Charlie  Ryan,  Software  Engineering  Institute 

•  Kevin  Schaaff,  Software  Engineering  Institute 

•  Alexander  Stall,  Software  Engineering  Institute 

•  Agapi  Svolou,  Software  Engineering  Institute 

•  Ron  Ulrich,  Northrop  Grumman 


CMMI  Version  1.3  Training  Teams 

The  two  training  teams  (one  for  CMMI-DEV  and  CMMI-ACQ  and  the  other 
for  CMMI-SVC)  developed  model  training  materials. 

ACQ  and  DEV  Training  Team 

•  Barbara  Baldwin,  Software  Engineering  Institute 

•  Bonnie  Bollinger,  Process  Focus  Management 

•  Cat  Brandt-Zaccardi,  Software  Engineering  Institute 

•  Rhonda  Brown,  Software  Engineering  Institute 

•  Michael  Campo,  Raytheon 

•  Mary  Beth  Chrissis,  Software  Engineering  Institute  (lead) 

•  Stacey  Cope,  Software  Engineering  Institute 

•  Eric  Dorsett,  Jeppesen 

•  Dan  Foster,  PF  Williamson 

•  Eric  Hayes,  Software  Engineering  Institute 

•  Kurt  Hess,  Software  Engineering  Institute 

•  Mike  Konrad,  Software  Engineering  Institute 

•  Steve  Masters,  Software  Engineering  Institute 

•  Robert  McFeeley,  Software  Engineering  Institute 

•  Diane  Mizukami-Williams,  Northrop  Grumman 

•  Daniel  Pipitone,  Software  Engineering  Institute 

•  Mary  Lou  Russo,  Software  Engineering  Institute  (non-voting  member) 

•  Sandy  Shrum,  Software  Engineering  Institute 


430 


CMMI  Version  1.3  Project  Participants 


CMMI  for  Development,  Version  1.3 


•  Katie  Smith-McGarty,  US  Navy 

•  Barbara  Tyson,  Software  Engineering  Institute 

SVC  Training  Team 

•  Drew  Allison,  Systems  and  Software  Consortium,  Inc. 

•  Mike  Bridges,  University  of  Pittsburgh  Medical  Center 

•  Paul  Byrnes,  Integrated  System  Diagnostics 

•  Sandra  Cepeda,  Cepeda  Systems  &  Software  Analysis/RDECOM  SED 

•  Eileen  Clark,  Tidewaters  Consulting 

•  Kieran  Doyle,  Excellence  in  Measurement 

•  Eileen  Forrester,  Software  Engineering  Institute  (lead  of  SVC  training) 

•  Suzanne  Miller,  Software  Engineering  Institute 

•  Hillel  Glazer,  Entinex 

•  Christian  Hertneck,  Anywhere. 24  GmbH 

•  Pat  Kirwan,  Software  Engineering  Institute 

•  Judah  Mogilensky,  PEP 

•  Heather  Oppenheimer,  Oppenheimer  Partners 

•  Pat  O’Toole,  PACT 

•  Agapi  Svolou,  Alexanna 

•  Jeff  Welch,  Software  Engineering  Institute 


CMMI  V1.3  Quality  Team _ 

The  Quality  team  conducts  various  quality  assurance  checks  on  the  model 
material  to  ensure  its  accuracy,  readability,  and  consistency. 

•  Rhonda  Brown,  Software  Engineering  Institute  (co-lead) 

•  Erin  Harper,  Software  Engineering  Institute 

•  Mike  Konrad,  Software  Engineering  Institute 

•  Mary  Lou  Russo,  Software  Engineering  Institute 

•  Mary  Lynn  Russo,  Software  Engineering  Institute 

•  Sandy  Shrum,  Software  Engineering  Institute  (co-lead) 
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Appendix  D:  Glossary 


The  glossary  defines  the  basic  terms  used  in  CMMI  models.  Glossary 
entries  are  typically  multiple-word  terms  consisting  of  a  noun  and  one  or 
more  restrictive  modifiers.  (There  are  some  exceptions  to  this  rule  that 
account  for  one-word  terms  in  the  glossary.) 

The  CMMI  glossary  of  terms  is  not  a  required,  expected,  or  informative 
component  of  CMMI  models.  Interpret  the  terms  in  the  glossary  in  the 
context  of  the  model  component  in  which  they  appear. 

To  formulate  definitions  appropriate  for  CMMI,  we  consulted  multiple 
sources.  We  first  consulted  the  Merham-Webster  OnLine  dictionary 
(http://www.merriam-webster.com/).  We  also  consulted  other  standards  as 
needed,  including  the  following: 

•  ISO  9000  [ISO  2005a] 

•  ISO/IEC  1 2207  [ISO  2008a] 

•  ISO/IEC  1 5504  [ISO  2006a] 

•  ISO/IEC  1 5288  [ISO  2008b] 

•  ISO/IEC  1 5939  [ISO  2007] 

•  ISO  20000-1  [ISO  2005b] 

•  IEEE  [IEEE  1991] 

•  CMM  for  Software  (SW-CMM)  v1 .1 

•  EIA  632  [EIA  2003] 

•  SA-CMM  [SEI  2002] 

•  People  CMM  (P-CMM)  [Curtis  2009] 

•  CoblT  V.  4.0  [IT  Governance  2005] 

•  ITIL  v3  (Service  Improvement,  Service  Design,  Service  Operation, 
Service  Strategy,  and  Service  Transition)  [Office  of  Government 
Commerce  2007] 

We  developed  the  glossary  recognizing  the  importance  of  using  terminology 
that  all  model  users  can  understand.  We  also  recognized  that  words  and 
terms  can  have  different  meanings  in  different  contexts  and  environments. 
The  glossary  in  CMMI  models  is  designed  to  document  the  meanings  of 
words  and  terms  that  should  have  the  widest  use  and  understanding  by 
users  of  CMMI  products. 

Even  though  the  term  “product”  includes  services  as  well  as  products  and 
the  term  “service”  is  defined  as  a  type  of  product,  many  of  the  terms  in  the 
glossary  contain  both  the  words  “product”  and  “service”  to  emphasize  that 
CMMI  applies  to  both  products  and  services. 


Glossary 
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acceptance  criteria 

acceptance  testing 

achievement  profile 

acquirer 
acquisition 
acquisition  strategy 

addition 

allocated 

requirement 


Every  glossary  entry  has  two  to  three  components.  There  is  always  a  term 
and  always  a  definition.  Sometimes  additional  notes  are  provided. 

The  term  defined  is  listed  on  the  left  side  of  the  page.  The  definition 
appears  first  in  a  type  size  similar  to  the  term  listed.  Glossary  notes  follow 
the  definition  and  are  in  a  smaller  type  size. 


The  criteria  that  a  deliverable  must  satisfy  to  be  accepted  by 
a  user,  customer,  or  other  authorized  entity.  (See  also 
“deliverable.”) 

Formal  testing  conducted  to  enable  a  user,  customer,  or 
other  authorized  entity  to  determine  whether  to  accept  a 
deliverable.  (See  also  “unit  testing.”) 

A  list  of  process  areas  and  their  corresponding  capability 
levels  that  represent  the  organization’s  progress  for  each 
process  area  while  advancing  through  the  capability  levels. 
(See  also  “capability  level  profile,”  “target  profile,”  and 
“target  staging.”) 

The  stakeholder  that  acquires  or  procures  a  product  or 
service  from  a  supplier.  (See  also  “stakeholder.”) 

The  process  of  obtaining  products  or  services  through 
supplier  agreements.  (See  also  “supplier  agreement.”) 

The  specific  approach  to  acquiring  products  and  services 
that  is  based  on  considerations  of  supply  sources, 
acquisition  methods,  requirements  specification  types, 
agreement  types,  and  related  acquisition  risks. 

A  clearly  marked  model  component  that  contains 
information  of  interest  to  particular  users. 

In  a  CMMI  model,  all  additions  bearing  the  same  name  can  be  optionally 
selected  as  a  group  for  use.  In  CMMI  for  Services,  the  Service  System 
Development  (SSD)  process  area  is  an  addition. 

Requirement  that  results  from  levying  all  or  part  of  a  higher 
level  requirement  on  a  lower  level  architectural  element  or 
design  component. 

More  generally,  requirements  can  be  allocated  to  other  logical  or  physical 
components  including  people,  consumables,  delivery  increments,  or  the 
architecture  as  a  whole,  depending  on  what  best  enables  the  product  or 
service  to  achieve  the  requirements. 
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appraisal 


appraisal  findings 

appraisal 

participants 

appraisal  rating 


appraisal  reference 
model 

appraisal  scope 

architecture 
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An  examination  of  one  or  more  processes  by  a  trained  team 
of  professionals  using  an  appraisal  reference  model  as  the 
basis  for  determining,  at  a  minimum,  strengths  and 
weaknesses. 

This  term  has  a  special  meaning  in  the  CMMI  Product  Suite  besides  its 
common  standard  English  meaning. 

The  results  of  an  appraisal  that  identify  the  most  important 
issues,  problems,  or  opportunities  for  process  improvement 
within  the  appraisal  scope. 

Appraisal  findings  are  inferences  drawn  from  corroborated  objective 
evidence. 

Members  of  the  organizational  unit  who  participate  in 
providing  information  during  an  appraisal. 

The  value  assigned  by  an  appraisal  team  to  (a)  a  CMMI  goal 
or  process  area,  (b)  the  capability  level  of  a  process  area,  or 
(c)  the  maturity  level  of  an  organizational  unit. 

This  term  is  used  in  CMMI  appraisal  materials  such  as  the  SCAMPI  MOD. 
A  rating  is  determined  by  enacting  the  defined  rating  process  for  the 
appraisal  method  being  employed. 

The  CMMI  model  to  which  an  appraisal  team  correlates 
implemented  process  activities. 

This  term  is  used  in  CMMI  appraisal  materials  such  as  the  SCAMPI  MOD. 

The  definition  of  the  boundaries  of  an  appraisal 
encompassing  the  organizational  limits  and  CMMI  model 
limits  within  which  the  processes  to  be  investigated  operate. 

This  term  is  used  in  CMMI  appraisal  materials  such  as  the  SCAMPI  MOD. 

The  set  of  structures  needed  to  reason  about  a  product. 
These  structures  are  comprised  of  elements,  relations 
among  them,  and  properties  of  both. 

In  a  service  context,  the  architecture  is  often  applied  to  the  service 
system. 

Note  that  functionality  is  only  one  aspect  of  the  product.  Quality  attributes, 
such  as  responsiveness,  reliability,  and  security,  are  also  important  to 
reason  about.  Structures  provide  the  means  for  highlighting  different 
portions  of  the  architecture.  (See  also  ‘‘functional  architecture.”) 
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audit 


baseline 


base  measure 


bidirectional 

traceability 


An  objective  examination  of  a  work  product  or  set  of  work 
products  against  specific  criteria  (e.g.,  requirements).  (See 
also  “objectively  evaluate.”) 

This  is  a  term  used  in  several  ways  in  CMMI,  Including  configuration 
audits  and  process  compliance  audits. 

A  set  of  specifications  or  work  products  that  has  been 
formally  reviewed  and  agreed  on,  which  thereafter  serves  as 
the  basis  for  further  development,  and  which  can  be 
changed  only  through  change  control  procedures.  (See  also 
“configuration  baseline”  and  “product  baseline.”) 

Measure  defined  in  terms  of  an  attribute  and  the  method  for 
quantifying  it.  (See  also  “derived  measure.”) 

A  base  measure  is  functionally  independent  of  other  measures. 

An  association  among  two  or  more  logical  entities  that  is 
discernable  in  either  direction  (i.e.,  to  and  from  an  entity). 
(See  also  “requirements  traceability”  and  “traceability.”) 


business  objectives 
capability  level 


capability  level 
profile 


capability  maturity 
model 


capable  process 


causal  analysis 


(See  “organization’s  business  objectives.”) 

Achievement  of  process  improvement  within  an  individual 
process  area.  (See  also  “generic  goal,”  “specific  goal,” 
“maturity  level,”  and  “process  area.”) 

A  capability  level  Is  defined  by  appropriate  specific  and  generic  goals  for 
a  process  area. 

A  list  of  process  areas  and  their  corresponding  capability 
levels.  (See  also  “achievement  profile,”  “target  profile,”  and 
“target  staging.”) 

A  capability  level  profile  can  be  an  “achievement  profile”  when  it 
represents  the  organization’s  progress  for  each  process  area  while 
advancing  through  the  capability  levels.  Or,  it  can  be  a  “target  profile” 
when  it  represents  an  objective  for  process  improvement. 

A  model  that  contains  the  essential  elements  of  effective 
processes  for  one  or  more  areas  of  interest  and  describes 
an  evolutionary  improvement  path  from  ad  hoc,  immature 
processes  to  disciplined,  mature  processes  with  improved 
quality  and  effectiveness. 

A  process  that  can  satisfy  its  specified  product  quality, 
service  quality,  and  process  performance  objectives.  (See 
also  “stable  process”  and  “standard  process.”) 

The  analysis  of  outcomes  to  determine  their  causes. 
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change 

management 


CMMI  Framework 


CMMI  model 


CMMI  model 
component 


CMMI  Product  Suite 
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Judicious  use  of  means  to  effect  a  change,  or  a  proposed 
change,  to  a  product  or  service.  (See  also  “configuration 
management.”) 

The  basic  structure  that  organizes  CMMI  components, 
including  elements  of  current  CMMI  models  as  well  as  rules 
and  methods  for  generating  models,  appraisal  methods 
(including  associated  artifacts),  and  training  materials.  (See 
also  “CMMI  model”  and  “CMMI  Product  Suite.”) 

The  framework  enables  new  areas  of  interest  to  be  added  to  CMMI  so 
that  they  will  integrate  with  the  existing  ones. 

A  model  generated  from  the  CMMI  Framework.  (See  also 
“CMMI  Framework”  and  “CMMI  Product  Suite.”) 

Any  of  the  main  architectural  elements  that  compose  a 
CMMI  model. 

Some  of  the  main  elements  of  a  CMMI  model  include  specific  practices, 
generic  practices,  specific  goals,  generic  goals,  process  areas,  capability 
levels,  and  maturity  levels. 

The  complete  set  of  products  developed  around  the  CMMI 
concept.  (See  also  “CMMI  Framework”  and  “CMMI  model.”) 

These  products  include  the  framework  itself,  models,  appraisal  methods, 
appraisal  materials,  and  training  materials. 

Items  that  can  be  purchased  from  a  commercial  supplier. 

The  variation  of  a  process  that  exists  because  of  normal  and 
expected  interactions  among  components  of  a  process. 

(See  also  “special  cause  of  variation.”) 

An  audit  conducted  to  verify  that  a  configuration  item  or  a 
collection  of  configuration  items  that  make  up  a  baseline 
conforms  to  a  specified  standard  or  requirement.  (See  also 
“audit”  and  “configuration  item.”) 

The  configuration  information  formally  designated  at  a 
specific  time  during  a  product’s  or  product  component’s  life. 
(See  also  “product  lifecycle.”) 

Configuration  baselines  plus  approved  changes  from  those  baselines 
constitute  the  current  configuration  information. 
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An  element  of  configuration  management  consisting  of  the 
evaluation,  coordination,  approval  or  disapproval,  and 
implementation  of  changes  to  configuration  items  after 
formal  establishment  of  their  configuration  identification. 

(See  also  “configuration  identification,”  “configuration  item,” 
and  “configuration  management.”) 

A  group  of  people  responsible  for  evaluating  and  approving 
or  disapproving  proposed  changes  to  configuration  items 
and  for  ensuring  implementation  of  approved  changes.  (See 
also  “configuration  item.”) 

Configuration  controi  boards  are  aiso  known  as  “change  controi  boards.” 

An  element  of  configuration  management  consisting  of 
selecting  the  configuration  items  for  a  product,  assigning 
unique  identifiers  to  them,  and  recording  their  functional  and 
physical  characteristics  in  technical  documentation.  (See 
also  “configuration  item,”  “configuration  management,”  and 
“product.”) 

An  aggregation  of  work  products  that  is  designated  for 
configuration  management  and  treated  as  a  single  entity  in 
the  configuration  management  process.  (See  also 
“configuration  management.”) 

A  discipline  applying  technical  and  administrative  direction 
and  surveillance  to  (1)  identify  and  document  the  functional 
and  physical  characteristics  of  a  configuration  item,  (2) 
control  changes  to  those  characteristics,  (3)  record  and 
report  change  processing  and  implementation  status,  and 
(4)  verify  compliance  with  specified  requirements.  (See  also 
“configuration  audit,”  “configuration  control,”  “configuration 
identification,”  and  “configuration  status  accounting.”) 

An  element  of  configuration  management  consisting  of  the 
recording  and  reporting  of  information  needed  to  manage  a 
configuration  effectively.  (See  also  “configuration 
identification”  and  “configuration  management.”) 

This  information  inciudes  a  iist  of  the  approved  configuration,  the  status  of 
proposed  changes  to  the  configuration,  and  the  impiementation  status  of 
approved  changes. 

A  collection  of  CMMI  components  that  are  used  to  construct 
models,  training  materials,  and  appraisal  related  documents 
for  an  area  of  interest  (e.g.,  acquisition,  development, 
services). 
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A  capability  maturity  model  structure  wherein  capability 
levels  provide  a  recommended  order  for  approaching 
process  improvement  within  each  specified  process  area. 
(See  also  “capability  level,”  “process  area,”  and  “staged 
representation.”) 

(See  “supplier.”) 

The  result  of  the  analysis  and  refinement  of  customer 
requirements  into  a  set  of  requirements  suitable  to  be 
included  in  one  or  more  solicitation  packages,  or  supplier 
agreements.  (See  also  “acquirer,”  “customer  requirement,” 
“supplier  agreement,”  and  “solicitation  package.”) 

Contractual  requirements  include  both  technical  and  nontechnical 
requirements  necessary  for  the  acquisition  of  a  product  or  service. 

Acts  or  deeds  used  to  remedy  a  situation  or  remove  an 
error. 

The  party  responsible  for  accepting  the  product  or  for 
authorizing  payment. 

The  customer  is  external  to  the  project  or  work  group  (except  possibly  in 
certain  project  structures  in  which  the  customer  effectively  is  on  the 
project  team  or  in  the  work  group)  but  not  necessarily  external  to  the 
organization.  The  customer  can  be  a  higher  level  project  or  work  group. 
Customers  are  a  subset  of  stakeholders.  (See  also  “stakeholder.”) 

In  most  cases  where  this  term  is  used,  the  preceding  definition  is 
intended;  however,  in  some  contexts,  the  term  “customer”  is  intended  to 
include  other  relevant  stakeholders.  (See  also  “customer  requirement.”) 

End  users  can  be  distinguished  from  customers  if  the  parties  that  directly 
receive  the  value  of  products  and  services  are  not  the  same  as  the 
parties  that  arrange  for,  pay  for,  or  negotiate  agreements.  In  contexts 
where  customers  and  end  users  are  essentially  the  same  parties,  the 
term  “customer”  can  encompass  both  types.  (See  also  “end  user.”) 

The  result  of  eliciting,  consolidating,  and  resolving  conflicts 
among  the  needs,  expectations,  constraints,  and  interfaces 
of  the  product’s  relevant  stakeholders  in  a  way  that  is 
acceptable  to  the  customer.  (See  also  “customer.”) 

Recorded  information. 

Recorded  information  can  include  technical  data,  computer  software 
documents,  financial  information,  management  information, 
representation  of  facts,  numbers,  or  datum  of  any  nature  that  can  be 
communicated,  stored,  and  processed. 
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The  disciplined  processes  and  systems  that  plan  for, 
acquire,  and  provide  stewardship  for  business  and  technical 
data,  consistent  with  data  requirements,  throughout  the  data 
lifecycle. 

Number  of  defects  per  unit  of  product  size. 

An  example  is  the  number  of  problem  reports  per  thousand  lines  of  code. 

A  managed  process  that  is  tailored  from  the  organization’s 
set  of  standard  processes  according  to  the  organization’s 
tailoring  guidelines;  has  a  maintained  process  description; 
and  contributes  process  related  experiences  to  the 
organizational  process  assets.  (See  also  “managed 
process.’’) 

A  characterization  of  required  functionality  and  quality 
attributes  obtained  through  “chunking,”  organizing, 
annotating,  structuring,  or  formalizing  the  requirements 
(functional  and  non-functional)  to  facilitate  further  refinement 
and  reasoning  about  the  requirements  as  well  as  (possibly, 
initial)  solution  exploration,  definition,  and  evaluation.  (See 
also  “architecture,”  “functional  architecture,”  and  “quality 
attribute.”) 

As  technical  solution  processes  progress,  this  characterization  can  be 
further  evolved  into  a  description  of  the  architecture  versus  simply  helping 
scope  and  guide  its  development,  depending  on  the  engineering 
processes  used;  requirements  specification  and  architectural  languages 
used;  and  the  tools  and  the  environment  used  for  product  or  service 
system  development. 

An  item  to  be  provided  to  an  acquirer  or  other  designated 
recipient  as  specified  in  an  agreement.  (See  also  “acquirer.”) 

This  item  can  be  a  document,  hardware  item,  software  item,  service,  or 
any  type  of  work  product. 
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The  complete  set  of  circumstances  and  conditions  under 
which  services  are  delivered  in  accordance  with  service 
agreements.  (See  also  “service”  and  “service  agreement.”) 

The  delivery  environment  encompasses  everything  that  has  or  can  have 
a  significant  effect  on  service  delivery,  including  but  not  limited  to  service 
system  operation,  natural  phenomena,  and  the  behavior  of  all  parties, 
whether  or  not  they  intend  to  have  such  an  effect.  For  example,  consider 
the  effect  of  weather  or  traffic  patterns  on  a  transportation  service.  (See 
also  “service  system.”) 

The  delivery  environment  is  uniquely  distinguished  from  other 
environments  (e.g.,  simulation  environments,  testing  environments).  The 
delivery  environment  is  the  one  in  which  services  are  actually  delivered 
and  count  as  satisfying  a  service  agreement. 

Measure  that  is  defined  as  a  function  of  two  or  more  values 
of  base  measures.  (See  also  “base  measure.”) 

Requirements  that  are  not  explicitly  stated  in  customer 
requirements  but  are  inferred  (1)  from  contextual 
requirements  (e.g.,  applicable  standards,  laws,  policies, 
common  practices,  management  decisions)  or  (2)  from 
requirements  needed  to  specify  a  product  or  service 
component. 

Derived  requirements  can  also  arise  during  analysis  and  design  of 
components  of  the  product  or  service.  (See  also  “product  requirements.”) 

A  formal,  documented,  comprehensive,  and  systematic 
examination  of  a  design  to  determine  if  the  design  meets  the 
applicable  requirements,  to  identify  problems,  and  to 
propose  solutions. 

To  create  a  product  or  service  system  by  deliberate  effort. 

In  some  contexts,  development  can  include  the  maintenance  of  the 
developed  product. 

A  collection  of  data,  regardless  of  the  medium  on  which  it  is 
recorded,  that  generally  has  permanence  and  can  be  read 
by  humans  or  machines. 

Documents  include  both  paper  and  electronic  documents. 
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A  party  that  ultimately  uses  a  delivered  product  or  that 
receives  the  benefit  of  a  delivered  service.  (See  also 
“customer.”) 

End  users  may  or  may  not  also  be  customers  (who  can  establish  and 
accept  agreements  or  authorize  payments). 

In  contexts  where  a  single  service  agreement  covers  multiple  service 
deliveries,  any  party  that  initiates  a  service  request  can  be  considered  an 
end  user.  (See  also  “service  agreement”  and  “service  request.”) 

The  full  composition  of  a  company.  (See  also 
“organization.”) 

A  company  can  consist  of  many  organizations  in  many  locations  with 
different  customers. 

States  of  being  that  must  be  present  before  an  effort  can 
begin  successfully. 

A  target  staging,  created  using  the  continuous 
representation  that  is  defined  so  that  the  results  of  using  the 
target  staging  can  be  compared  to  maturity  levels  of  the 
staged  representation.  (See  also  “capability  level  profile,” 
“maturity  level,”  “target  profile,”  and  “target  staging.”) 

Such  staging  permits  benchmarking  of  progress  among  organizations, 
enterprises,  projects,  and  workgroups,  regardless  of  the  CMMI 
representation  used.  The  organization  can  implement  components  of 
CMMI  models  beyond  the  ones  reported  as  part  of  equivalent  staging. 
Equivalent  staging  relates  how  the  organization  compares  to  other 
organizations  in  terms  of  maturity  levels. 

Create,  document,  use,  and  revise  work  products  as 
necessary  to  ensure  they  remain  useful. 

The  phrase  “establish  and  maintain”  plays  a  special  role  in 
communicating  a  deeper  principle  in  CMMI:  work  products  that  have  a 
central  or  key  role  in  work  group,  project,  and  organizational  performance 
should  be  given  attention  to  ensure  they  are  used  and  useful  in  that  role. 

This  phrase  has  particular  significance  in  CMMI  because  it  often  appears 
in  goal  and  practice  statements  (though  in  the  former  as  "established  and 
maintained")  and  should  be  taken  as  shorthand  for  applying  the  principle 
to  whatever  work  product  is  the  object  of  the  phrase. 

An  informative  model  component  that  provides  sample 
outputs  from  a  specific  practice. 

(See  “senior  manager.”) 
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States  of  being  that  must  be  present  before  an  effort  can 
end  successfully. 

CMMI  components  that  describe  the  activities  that  are 
important  in  achieving  a  required  CMMI  component. 

Model  users  can  implement  the  expected  components  explicitly  or 
implement  equivalent  practices  to  these  components.  Specific  and 
generic  practices  are  expected  model  components. 

(See  “appraisal  findings.”) 

A  structured  approach  to  evaluating  alternative  solutions 
against  established  criteria  to  determine  a  recommended 
solution  to  address  an  issue. 

(See  “CMMI  Framework.”) 

Examination  of  a  defined  function  to  identify  all  the 
subfunctions  necessary  to  accomplish  that  function; 
identification  of  functional  relationships  and  interfaces 
(internal  and  external)  and  capturing  these  relationships  and 
interfaces  in  a  functional  architecture;  and  flow  down  of 
upper  level  requirements  and  assignment  of  these 
requirements  to  lower  level  subfunctions.  (See  also 
“functional  architecture.”) 

The  hierarchical  arrangement  of  functions,  their  internal  and 
external  (external  to  the  aggregation  itself)  functional 
interfaces  and  external  physical  interfaces,  their  respective 
requirements,  and  their  design  constraints.  (See  also 
“architecture,”  “functional  analysis,”  and  “definition  of 
required  functionality  and  quality  attributes.”) 

A  required  model  component  that  describes  characteristics 
that  must  be  present  to  institutionalize  processes  that 
implement  a  process  area.  (See  also  “institutionalization.”) 

An  expected  model  component  that  is  considered  important 
in  achieving  the  associated  generic  goal. 

The  generic  practices  associated  with  a  generic  goal  describe  the 
activities  that  are  expected  to  result  in  achievement  of  the  generic  goal 
and  contribute  to  the  institutionalization  of  the  processes  associated  with 
a  process  area. 

An  informative  model  component  that  appears  after  a 
generic  practice  to  provide  guidance  on  how  the  generic 
practice  could  be  applied  uniquely  to  a  process  area.  (This 
model  component  is  not  present  in  all  CMMI  models.) 
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The  application  of  a  systematic,  disciplined,  and  quantifiable 
approach  to  transforming  a  set  of  requirements  that 
represent  the  collection  of  stakeholder  needs,  expectations, 
and  constraints,  using  documented  techniques  and 
technology  to  design,  implement,  and  maintain  a  tangible 
product.  (See  also  “software  engineering”  and  “systems 
engineering.”) 

In  CMMI,  hardware  engineering  represents  all  technical  fields  (e.g., 
electrical,  mechanical)  that  transform  requirements  and  ideas  into 
tangible  products. 

The  person  or  persons  who  provide  the  policy  and  overall 
guidance  for  the  process  but  do  not  provide  the  direct  day- 
to-day  monitoring  and  controlling  of  the  process.  (See  also 
“senior  manager.”) 

Such  persons  belong  to  a  level  of  management  in  the  organization  above 
the  immediate  level  responsible  for  the  process  and  can  be  (but  are  not 
necessarily)  senior  managers. 

A  process  that  is  not  performed  or  is  performed  only 
partially;  one  or  more  of  the  specific  goals  of  the  process 
area  are  not  satisfied. 

An  incomplete  process  is  also  known  as  capability  level  0. 

CMMI  components  that  help  model  users  understand  the 
required  and  expected  components  of  a  model. 

These  components  can  be  examples,  detailed  explanations,  or  other 
helpful  information.  Subpractices,  notes,  references,  goal  titles,  practice 
titles,  sources,  example  work  products,  and  generic  practice  elaborations 
are  informative  model  components. 

The  ingrained  way  of  doing  business  that  an  organization 
follows  routinely  as  part  of  its  corporate  culture. 

In  configuration  management,  the  process  of  (1)  identifying 
all  functional  and  physical  characteristics  relevant  to  the 
interfacing  of  two  or  more  configuration  items  provided  by 
one  or  more  organizations  and  (2)  ensuring  that  proposed 
changes  to  these  characteristics  are  evaluated  and 
approved  prior  to  implementation.  (See  also  “configuration 
item”  and  “configuration  management.”) 

A  partitioning  of  the  life  of  a  product,  service,  project,  work 
group,  or  set  of  work  activities  into  phases. 
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A  performed  process  that  is  planned  and  executed  in 
accordance  with  policy;  employs  skilled  people  having 
adequate  resources  to  produce  controlled  outputs;  involves 
relevant  stakeholders;  is  monitored,  controlled,  and 
reviewed;  and  is  evaluated  for  adherence  to  its  process 
description.  (See  also  “performed  process.”) 

A  person  who  provides  technical  and  administrative 
direction  and  control  to  those  who  perform  tasks  or  activities 
within  the  manager’s  area  of  responsibility. 

This  term  has  a  special  meaning  in  the  CMMI  Product  Suite  besides  its 
common  standard  English  meaning.  The  traditional  functions  of  a 
manager  include  planning,  organizing,  directing,  and  controlling  work 
within  an  area  of  responsibility. 

Degree  of  process  improvement  across  a  predefined  set  of 
process  areas  in  which  all  goals  in  the  set  are  attained.  (See 
also  “capability  level”  and  “process  area.”) 

Variable  to  which  a  value  is  assigned  as  a  result  of 
measurement.  (See  also  “base  measure,”  “derived 
measure,”  and  “measurement.”) 

The  definition  of  this  term  in  CMMI  is  consistent  with  the  definition  of  this 
term  in  ISO  15939. 

A  set  of  operations  to  determine  the  value  of  a  measure. 
(See  also  “measure.”) 

The  definition  of  this  term  in  CMMI  is  consistent  with  the  definition  of  this 
term  in  ISO  15939. 

A  value  determined  by  performing  a  measurement.  (See 
also  “measurement.”) 

Binding  document  of  understanding  or  agreement  between 
two  or  more  parties. 

A  memorandum  of  agreement  is  also  known  as  a  “memorandum  of 
understanding.” 

The  inherent  range  of  variation  in  a  process,  as  determined 
by  process  performance  measures. 

Natural  bounds  are  sometimes  referred  to  as  “voice  of  the  process.” 

Techniques  such  as  control  charts,  confidence  intervals,  and  prediction 
intervals  are  used  to  determine  whether  the  variation  is  due  to  common 
causes  (i.e.,  the  process  is  predictable  or  stable)  or  is  due  to  some 
special  cause  that  can  and  should  be  identified  and  removed.  (See  also 
“measure”  and  “process  performance.”) 
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An  item  that  was  developed  prior  to  its  current  use  in  an 
acquisition  or  development  process. 

Such  an  item  can  require  minor  modifications  to  meet  the  requirements  of 
its  current  intended  use. 

Requirements  affecting  product  and  service  acquisition  or 
development  that  are  not  properties  of  the  product  or 
service. 

Examples  include  numbers  of  products  or  sen/ices  to  be  delivered,  data 
rights  for  delivered  COTS  and  nondevelopmental  items,  delivery  dates, 
and  milestones  with  exit  criteria.  Other  nontechnical  requirements  include 
work  constraints  associated  with  training,  site  provisions,  and  deployment 
schedules. 

To  review  activities  and  work  products  against  criteria  that 
minimize  subjectivity  and  bias  by  the  reviewer.  (See  also 
“audit.”) 

An  example  of  an  objective  evaluation  is  an  audit  against  requirements, 
standards,  or  procedures  by  an  independent  quality  assurance  function. 

A  general  description  of  the  way  in  which  an  entity  is  used  or 
operates. 

An  operational  concept  is  also  known  as  “concept  of  operations.” 

A  description  of  an  imagined  sequence  of  events  that 
includes  the  interaction  of  the  product  or  service  with  its 
environment  and  users,  as  well  as  interaction  among  its 
product  or  service  components. 

Operational  scenarios  are  used  to  evaluate  the  requirements  and  design 
of  the  system  and  to  verify  and  validate  the  system. 

An  administrative  structure  in  which  people  collectively 
manage  one  or  more  projects  or  work  groups  as  a  whole, 
share  a  senior  manager,  and  operate  under  the  same 
policies. 

However,  the  word  “organization”  as  used  throughout  CMMI  models  can 
also  apply  to  one  person  who  performs  a  function  in  a  small  organization 
that  might  be  performed  by  a  group  of  people  in  a  large  organization. 

(See  also  “enterprise.”) 

The  extent  to  which  an  organization  has  explicitly  and 
consistently  deployed  processes  that  are  documented, 
managed,  measured,  controlled,  and  continually  improved. 

Organizational  maturity  can  be  measured  via  appraisals. 
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organizational 

policy 


organizational 
process  assets 


organization’s 
business  objectives 


organization’s 

measurement 

repository 


organization’s 
process  asset 
library 


organization’s  set  of 
standard  processes 


outsourcing 


A  guiding  principle  typically  established  by  senior 
management  that  is  adopted  by  an  organization  to  influence 
and  determine  decisions. 

Artifacts  that  relate  to  describing,  implementing,  and 
improving  processes. 

Examples  of  these  artifacts  include  policies,  measurement  descriptions, 
process  descriptions,  process  implementation  support  tools. 

The  term  ‘‘process  assets”  is  used  to  indicate  that  these  artifacts  are 
developed  or  acquired  to  meet  the  business  objectives  of  the  organization 
and  that  they  represent  investments  by  the  organization  that  are  expected 
to  provide  current  and  future  business  value.  (See  also  ‘‘process  asset 
library.”) 

Senior-management-developed  objectives  designed  to 
ensure  an  organization’s  continued  existence  and  enhance 
its  profitability,  market  share,  and  other  factors  influencing 
the  organization’s  success.  (See  also  “quality  and  process 
performance  objectives”  and  “quantitative  objective.”) 

A  repository  used  to  collect  and  make  measurement  results 
available  on  processes  and  work  products,  particularly  as 
they  relate  to  the  organization’s  set  of  standard  processes. 

This  repository  contains  or  references  actual  measurement  results  and 
related  information  needed  to  understand  and  analyze  measurement 
results. 

A  library  of  information  used  to  store  and  make  process 
assets  available  that  are  useful  to  those  who  are  defining, 
implementing,  and  managing  processes  in  the  organization. 

This  library  contains  process  assets  that  include  process  related 
documentation  such  as  policies,  defined  processes,  checklists,  lessons 
learned  documents,  templates,  standards,  procedures,  plans,  and  training 
materials. 

A  collection  of  definitions  of  the  processes  that  guide 
activities  in  an  organization. 

These  process  descriptions  cover  the  fundamental  process  elements 
(and  their  relationships  to  each  other  such  as  ordering  and  interfaces) 
that  should  be  incorporated  into  the  defined  processes  that  are 
implemented  in  projects,  work  groups,  and  work  across  the  organization. 
A  standard  process  enables  consistent  development  and  maintenance 
activities  across  the  organization  and  is  essential  for  long-term  stability 
and  improvement.  (See  also  “defined  process”  and  “process  element.”) 

(See  “acquisition.”) 
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peer  review 


performance 

parameters 

performed  process 


planned  process 


policy 


The  review  of  work  products  performed  by  peers  during  the 
development  of  work  products  to  identify  defects  for 
removal.  (See  also  “work  product.”) 

The  term  “peer  review”  is  used  in  the  CMMI  Product  Suite  instead  of  the 
term  “work  product  inspection.” 

The  measures  of  effectiveness  and  other  key  measures 
used  to  guide  and  control  progressive  development. 

A  process  that  accomplishes  the  needed  work  to  produce 
work  products;  the  specific  goals  of  the  process  area  are 
satisfied. 

A  process  that  is  documented  by  both  a  description  and  a 
plan. 

The  description  and  plan  should  be  coordinated  and  the  plan  should 
include  standards,  requirements,  objectives,  resources,  and  assignments. 

(See  “organizational  policy.”) 


process 


process  action  plan 


process  action  team 


process  and 

technology 

Improvements 


A  set  of  interrelated  activities,  which  transform  inputs  into 
outputs,  to  achieve  a  given  purpose.  (See  also  “process 
area,”  “subprocess,”  and  “process  element.”) 

There  is  a  special  use  of  the  phrase  “the  process”  in  the  statements  and 
descriptions  of  the  generic  goals  and  generic  practices.  “The  process,”  as 
used  in  Part  Two,  is  the  process  or  processes  that  implement  the  process 
area. 

The  terms  “process,”  “subprocess”  and  “process  element”  form  a 
hierarchy  with  “process”  as  the  highest,  most  general  term, 
“subprocesses”  below  it,  and  “process  element”  as  the  most  specific.  A 
particular  process  can  be  called  a  subprocess  if  it  is  part  of  another  larger 
process.  It  can  also  be  called  a  process  element  if  it  is  not  decomposed 
into  subprocesses. 

This  definition  of  process  is  consistent  with  the  definition  of  process  in 
ISO  9000,  ISO  12207,  ISO  15504,  and  EIA  731. 

A  plan,  usually  resulting  from  appraisals,  that  documents 
how  specific  improvements  targeting  the  weaknesses 
uncovered  by  an  appraisal  will  be  implemented. 

A  team  that  has  the  responsibility  to  develop  and  implement 
process  improvement  activities  for  an  organization  as 
documented  in  a  process  action  plan. 

Incremental  and  innovative  improvements  to  processes  and 
to  process,  product,  or  service  technologies. 
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process 

architecture 


process  area 


process  asset 

process  asset 
library 

process  attribute 
process  capability 
process  definition 

process  description 


(1)  The  ordering,  interfaces,  interdependencies,  and  other 
relationships  among  the  process  elements  in  a  standard 
process,  or  (2)  the  interfaces,  interdependencies,  and  other 
relationships  between  process  elements  and  external 
processes. 

A  cluster  of  related  practices  in  an  area  that,  when 
implemented  collectively,  satisfies  a  set  of  goals  considered 
important  for  making  improvement  in  that  area. 

Anything  the  organization  considers  useful  in  attaining  the 
goals  of  a  process  area.  (See  also  “organizational  process 
assets.”) 

A  collection  of  process  asset  holdings  that  can  be  used  by 
an  organization,  project,  or  workgroup.  (See  also 
“organization’s  process  asset  library.”) 

A  measurable  characteristic  of  process  capability  applicable 
to  any  process. 

The  range  of  expected  results  that  can  be  achieved  by 
following  a  process. 

The  act  of  defining  and  describing  a  process. 

The  result  of  process  definition  is  a  process  description.  (See  also 
“process  description.”) 

A  documented  expression  of  a  set  of  activities  performed  to 
achieve  a  given  purpose. 

A  process  description  provides  an  operational  definition  of  the  major 
components  of  a  process.  The  description  specifies,  in  a  complete, 
precise,  and  verifiable  manner,  the  requirements,  design,  behavior,  or 
other  characteristics  of  a  process.  It  also  can  include  procedures  for 
determining  whether  these  provisions  have  been  satisfied.  Process 
descriptions  can  be  found  at  the  activity,  project,  work  group,  or 
organizational  level. 
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process  element 


process  group 


process 

improvement 


process 

improvement 

objectives 


process 

improvement  plan 


process 

measurement 


The  fundamental  unit  of  a  process. 

A  process  can  be  defined  in  terms  of  subprocesses  or  process  elements. 
A  subprocess  is  a  process  element  when  it  is  not  further  decomposed  into 
subprocesses  or  process  elements.  (See  also  "process”  and 
"subprocess.”) 

Each  process  element  covers  a  closely  related  set  of  activities  (e.g., 
estimating  element,  peer  review  element).  Process  elements  can  be 
portrayed  using  templates  to  be  completed,  abstractions  to  be  refined,  or 
descriptions  to  be  modified  or  used.  A  process  element  can  be  an  activity 
or  task. 

The  terms  "process,”  "subprocess,”  and  "process  element”  form  a 
hierarchy  with  "process”  as  the  highest,  most  general  term, 
"subprocesses”  below  it,  and  "process  element”  as  the  most  specific. 

A  collection  of  specialists  who  facilitate  the  definition, 
maintenance,  and  improvement  of  processes  used  by  the 
organization. 

A  program  of  activities  designed  to  improve  the  process 
performance  and  maturity  of  the  organization’s  processes, 
and  the  results  of  such  a  program. 

A  set  of  target  characteristics  established  to  guide  the  effort 
to  improve  an  existing  process  in  a  specific,  measurable 
way  either  in  terms  of  resultant  product  or  service 
characteristics  (e.g.,  quality,  product  performance, 
conformance  to  standards)  or  in  the  way  in  which  the 
process  is  executed  (e.g.,  elimination  of  redundant  process 
steps,  combination  of  process  steps,  improvement  of  cycle 
time).  (See  also  “organization’s  business  objectives”  and 
“quantitative  objective.”) 

A  plan  for  achieving  organizational  process  improvement 
objectives  based  on  a  thorough  understanding  of  current 
strengths  and  weaknesses  of  the  organization’s  processes 
and  process  assets. 

A  set  of  operations  used  to  determine  values  of  measures  of 
a  process  and  its  resulting  products  or  services  for  the 
purpose  of  characterizing  and  understanding  the  process. 
(See  also  “measurement.”) 
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process  owner 


process 

performance 


process 

performance 

baseline 


process 

performance  model 


process  tailoring 


The  person  (or  team)  responsible  for  defining  and 
maintaining  a  process. 

At  the  organizational  level,  the  process  owner  is  the  person  (or  team) 
responsible  for  the  description  of  a  standard  process;  at  the  project  or 
work  group  level,  the  process  owner  is  the  person  (or  team)  responsible 
for  the  description  of  the  defined  process.  A  process  can  therefore  have 
multiple  owners  at  different  levels  of  responsibility.  (See  also  ‘‘defined 
process”  and  ‘‘standard  process.”) 

A  measure  of  results  achieved  by  following  a  process.  (See 
also  “measure.”) 

Process  performance  is  characterized  by  both  process  measures  (e.g., 
effort,  cycle  time,  defect  removal  efficiency)  and  product  or  service 
measures  (e.g.,  reliability,  defect  density,  response  time). 

A  documented  characterization  of  process  performance, 
which  can  include  central  tendency  and  variation.  (See  also 
“process  performance.”) 

A  process  performance  baseline  can  be  used  as  a  benchmark  for 
comparing  actual  process  performance  against  expected  process 
performance. 

A  description  of  relationships  among  the  measurable 
attributes  of  one  or  more  processes  or  work  products  that  is 
developed  from  historical  process  performance  data  and  is 
used  to  predict  future  performance.  (See  also  “measure.”) 

One  or  more  of  the  measureable  attributes  represent  controllable  inputs 
tied  to  a  subprocess  to  enable  performance  of  “what-if  analyses  for 
planning,  dynamic  re-planning,  and  problem  resolution.  Process 
performance  models  include  statistical,  probabilistic  and  simulation  based 
models  that  predict  interim  or  final  results  by  connecting  past 
performance  with  future  outcomes.  They  model  the  variation  of  the 
factors,  and  provide  insight  into  the  expected  range  and  variation  of 
predicted  results.  A  process  performance  model  can  be  a  collection  of 
models  that  (when  combined)  meet  the  criteria  of  a  process  performance 
model. 

Making,  altering,  or  adapting  a  process  description  for  a 
particular  end. 

For  example,  a  project  or  work  group  tailors  its  defined  process  from  the 
organization’s  set  of  standard  processes  to  meet  objectives,  constraints, 
and  the  environment  of  the  project  or  work  group.  (See  also  “defined 
process,”  “organization’s  set  of  standard  processes,”  and  “process 
description.”) 
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product 

product  baseline 

product  component 


product  component 
requirements 

product  lifecycle 


A  work  product  that  is  intended  for  delivery  to  a  customer  or 
end  user. 

This  term  has  a  special  meaning  in  the  CMMI  Product  Suite  besides  its 
common  standard  English  meaning.  The  form  of  a  product  can  vary  in 
different  contexts.  (See  also  "customer,”  "product  component,”  "service,” 
and  "work  product.”) 

The  initial  approved  technical  data  package  defining  a 
configuration  item  during  the  production,  operation, 
maintenance,  and  logistic  support  of  its  lifecycle.  (See  also 
“configuration  item,”  “configuration  management,”  and 
“technical  data  package.”) 

This  term  is  related  to  configuration  management. 

A  work  product  that  is  a  lower  level  component  of  the 
product.  (See  also  “product”  and  “work  product.”) 

Product  components  are  integrated  to  produce  the  product.  There  can  be 
multiple  levels  of  product  components. 

Throughout  the  process  areas,  where  the  terms  "product”  and  "product 
component”  are  used,  their  intended  meanings  also  encompass  services, 
service  systems,  and  their  components. 

This  term  has  a  special  meaning  in  the  CMMI  Product  Suite  besides  its 
common  standard  English  meaning. 

A  complete  specification  of  a  product  or  service  component, 
including  fit,  form,  function,  performance,  and  any  other 
requirement. 

The  period  of  time,  consisting  of  phases,  that  begins  when  a 
product  or  service  is  conceived  and  ends  when  the  product 
or  service  is  no  longer  available  for  use. 

Since  an  organization  can  be  producing  multiple  products  or  services  for 
multiple  customers,  one  description  of  a  product  lifecycle  may  not  be 
adequate.  Therefore,  the  organization  can  define  a  set  of  approved 
product  lifecycle  models.  These  models  are  typically  found  in  published 
literature  and  are  likely  to  be  tailored  for  use  in  an  organization. 

A  product  lifecycle  could  consist  of  the  following  phases:  (1 )  concept  and 
vision,  (2)  feasibility,  (3)  design/development,  (4)  production,  and  (5) 
phase  out. 
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product  line 


product  related 
lifecycle  processes 


product 

requirements 


product  suite 
project 


A  group  of  products  sharing  a  common,  managed  set  of 
features  that  satisfy  specific  needs  of  a  selected  market  or 
mission  and  that  are  developed  from  a  common  set  of  core 
assets  in  a  prescribed  way.  (See  also  “service  line.”) 

The  development  or  acquisition  of  products  for  the  product  line  is  based 
on  exploiting  commonality  and  bounding  variation  (i.e.,  restricting 
unnecessary  product  variation)  across  the  group  of  products.  The 
managed  set  of  core  assets  (e.g.,  requirements,  architectures, 
components,  tools,  testing  artifacts,  operating  procedures,  software) 
includes  prescriptive  guidance  for  their  use  in  product  development. 
Product  line  operations  involve  interlocking  execution  of  the  broad 
activities  of  core  asset  development,  product  development,  and 
management. 

Many  people  use  “product  line”  just  to  mean  the  set  of  products  produced 
by  a  particular  business  unit,  whether  they  are  built  with  shared  assets  or 
not.  We  call  that  collection  a  "portfolio,"  and  reserve  "product  line"  to  have 
the  technical  meaning  given  here. 

Processes  associated  with  a  product  or  service  throughout 
one  or  more  phases  of  its  life  (e.g.,  from  conception  through 
disposal),  such  as  manufacturing  and  support  processes. 

A  refinement  of  customer  requirements  into  the  developers’ 
language,  making  implicit  requirements  into  explicit  derived 
requirements.  (See  also  “derived  requirements”  and 
“product  component  requirements.”) 

The  developer  uses  product  requirements  to  guide  the  design  and 
building  of  the  product  or  service. 

(See  “CMMI  Product  Suite.”) 

A  managed  set  of  interrelated  activities  and  resources, 
including  people,  that  delivers  one  or  more  products  or 
services  to  a  customer  or  end  user. 

A  project  has  an  intended  beginning  (i.e.,  project  startup)  and  end. 
Projects  typically  operate  according  to  a  plan.  Such  a  plan  is  frequently 
documented  and  specifies  what  is  to  be  delivered  or  implemented,  the 
resources  and  funds  to  be  used,  the  work  to  be  done,  and  a  schedule  for 
doing  the  work.  A  project  can  be  composed  of  projects.  (See  also  “project 
startup.”) 

In  some  contexts,  the  term  “program”  is  used  to  refer  to  a  project. 
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project  plan 

project  progress 
and  performance 

project  startup 

prototype 


quality 

quality  and  process 

performance 

objectives 


A  plan  that  provides  the  basis  for  performing  and  controlling 
the  project’s  activities,  which  addresses  the  commitments  to 
the  project’s  customer. 

Project  planning  includes  estimating  the  attributes  of  work  products  and 
tasks,  determining  the  resources  needed,  negotiating  commitments, 
producing  a  schedule,  and  identifying  and  analyzing  project  risks. 

Iterating  through  these  activities  may  be  necessary  to  establish  the 
project  plan. 

What  a  project  achieves  with  respect  to  implementing 
project  plans,  including  effort,  cost,  schedule,  and  technical 
performance.  (See  also  “technical  performance.’’) 

When  a  set  of  interrelated  resources  for  a  project  are 
directed  to  develop  or  deliver  one  or  more  products  or 
services  for  a  customer  or  end  user.  (See  also  “project.”) 

A  preliminary  type,  form,  or  instance  of  a  product,  service, 
product  component,  or  service  component  that  serves  as  a 
model  for  later  stages  or  for  the  final,  complete  version  of 
the  product  or  service. 

This  model  of  the  product  or  service  (e.g.,  physical,  electronic,  digital, 
analytical)  can  be  used  for  the  following  (and  other)  purposes: 

•  Assessing  the  feasibility  of  a  new  or  unfamiliar  technology 

•  Assessing  or  mitigating  technical  risk 

•  Validating  requirements 

•  Demonstrating  critical  features 

•  Qualifying  a  product  or  service 

•  Qualifying  a  process 

•  Characterizing  performance  or  features  of  the  product  or  service 

•  Elucidating  physical  principles 

The  degree  to  which  a  set  of  inherent  characteristics  fulfills 
requirements. 

Quantitative  objectives  and  requirements  for  product  quality, 
service  quality,  and  process  performance. 

Quantitative  process  performance  objectives  include  quality;  however,  to 
emphasize  the  importance  of  quality  in  the  CMMI  Product  Suite,  the 
phrase  “quality  and  process  performance  objectives”  is  used.  “Process 
performance  objectives”  are  referenced  in  maturity  level  3;  the  term 
“quality  and  process  performance  objectives”  implies  the  use  of 
quantitative  data  and  is  only  used  in  maturity  levels  4  and  5. 
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quality  assurance 


quality  attribute 


quality  control 


quantitative 

management 


quantitative 

objective 

quantitatively 

managed 

reference  model 

relevant  stakeholder 

representation 


A  planned  and  systematic  means  for  assuring  management 
that  the  defined  standards,  practices,  procedures,  and 
methods  of  the  process  are  applied. 

A  property  of  a  product  or  service  by  which  its  quality  will  be 
judged  by  relevant  stakeholders.  Quality  attributes  are 
characterizable  by  some  appropriate  measure. 

Quality  attributes  are  non-functional,  such  as  timeliness,  throughput, 
responsiveness,  security,  modifiability,  reliability,  and  usability.  They  have 
a  significant  influence  on  the  architecture. 

The  operational  techniques  and  activities  that  are  used  to 
fulfill  requirements  for  quality.  (See  also  “quality 
assurance.”) 

Managing  a  project  or  work  group  using  statistical  and  other 
quantitative  techniques  to  build  an  understanding  of  the 
performance  or  predicted  performance  of  processes  in 
comparison  to  the  project’s  or  work  group’s  quality  and 
process  performance  objectives,  and  identifying  corrective 
action  that  may  need  to  be  taken.  (See  also  “statistical 
techniques.”) 

Statistical  techniques  used  in  quantitative  management  include  analysis, 
creation,  or  use  of  process  performance  models;  analysis,  creation,  or 
use  of  process  performance  baselines;  use  of  control  charts;  analysis  of 
variance,  regression  analysis;  and  use  of  confidence  intervals  or 
prediction  intervals,  sensitivity  analysis,  simulations,  and  tests  of 
hypotheses. 

Desired  target  value  expressed  using  quantitative 
measures.  (See  also  “measure,”  “process  improvement 
objectives,”  and  “quality  and  process  performance 
objectives.”) 

(See  “quantitative  management.”) 

A  model  that  is  used  as  a  benchmark  for  measuring  an 
attribute. 

A  stakeholder  that  is  identified  for  involvement  in  specified 
activities  and  is  included  in  a  plan.  (See  also  “stakeholder.”) 

The  organization,  use,  and  presentation  of  a  CMM’s 
components. 

Overall,  two  types  of  approaches  to  presenting  best  practices  are  evident: 
the  staged  representation  and  the  continuous  representation. 
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required  CMMI 
components 


requirement 


requirements 

analysis 


requirements 

elicitation 


requirements 

management 


requirements 

traceability 


return  on 
investment 


risk  analysis 
risk  identification 


CMMI  components  that  are  essential  to  achieving  process 
improvement  in  a  given  process  area. 

Specific  goals  and  generic  goals  are  required  model  components.  Goal 
satisfaction  is  used  in  appraisals  as  the  basis  for  deciding  whether  a 
process  area  has  been  satisfied. 

(1 )  A  condition  or  capability  needed  by  a  user  to  solve  a 
problem  or  achieve  an  objective.  (2)  A  condition  or  capability 
that  must  be  met  or  possessed  by  a  product,  service, 
product  component,  or  service  component  to  satisfy  a 
supplier  agreement,  standard,  specification,  or  other 
formally  imposed  documents.  (3)  A  documented 
representation  of  a  condition  or  capability  as  in  (1)  or  (2). 
(See  also  “supplier  agreement.”) 

The  determination  of  product  or  service  specific  functional 
and  quality  attribute  characteristics  based  on  analyses  of 
customer  needs,  expectations,  and  constraints;  operational 
concept;  projected  utilization  environments  for  people, 
products,  services,  and  processes;  and  measures  of 
effectiveness.  (See  also  “operational  concept.”) 

Using  systematic  techniques  such  as  prototypes  and 
structured  surveys  to  proactively  identify  and  document 
customer  and  end-user  needs. 

The  management  of  all  requirements  received  by  or 
generated  by  the  project  or  work  group,  including  both 
technical  and  nontechnical  requirements  as  well  as  those 
requirements  levied  on  the  project  or  work  group  by  the 
organization.  (See  also  “nontechnical  requirements.”) 

A  discernable  association  between  requirements  and  related 
requirements,  implementations,  and  verifications.  (See  also 
“bidirectional  traceability”  and  “traceability.”) 

The  ratio  of  revenue  from  output  (product  or  service)  to 
production  costs,  which  determines  whether  an  organization 
benefits  from  performing  an  action  to  produce  something. 

The  evaluation,  classification,  and  prioritization  of  risks. 

An  organized,  thorough  approach  used  to  seek  out  probable 
or  realistic  risks  in  achieving  objectives. 
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risk  management 


senior  manager 


service 


An  organized,  analytic  process  used  to  identify  what  might 
cause  harm  or  loss  (identify  risks);  to  assess  and  quantify 
the  identified  risks;  and  to  develop  and,  if  needed, 
implement  an  appropriate  approach  to  prevent  or  handle 
causes  of  risk  that  could  result  in  significant  harm  or  loss. 

Typically,  risk  management  is  performed  for  the  activities  of  a  project,  a 
work  group,  an  organization,  or  other  organizational  units  that  are 
developing  or  delivering  products  or  services. 

A  management  role  at  a  high  enough  level  in  an 
organization  that  the  primary  focus  of  the  person  filling  the 
role  is  the  long-term  vitality  of  the  organization  rather  than 
short-term  concerns  and  pressures.  (See  also  “higher  level 
management.”) 

A  senior  manager  has  authority  to  direct  the  allocation  or  reallocation  of 
resources  in  support  of  organizational  process  improvement 
effectiveness. 

A  senior  manager  can  be  any  manager  who  satisfies  this  description, 
including  the  head  of  the  organization.  Synonyms  for  senior  manager 
include  “executive”  and  “top-level  manager.”  However,  to  ensure 
consistency  and  usability,  these  synonyms  are  not  used  in  CMMI  models. 

This  term  has  a  special  meaning  in  the  CMMI  Product  Suite  besides  its 
common  standard  English  meaning. 

A  product  that  is  intangible  and  non-storable.  (See  also 
“product,”  “customer,”  and  “work  product.”) 

Services  are  delivered  through  the  use  of  service  systems  that  have  been 
designed  to  satisfy  service  requirements.  (See  also  “service  system.”) 

Many  service  providers  deliver  combinations  of  services  and  goods.  A 
single  service  system  can  deliver  both  types  of  products.  For  example,  a 
training  organization  can  deliver  training  materials  along  with  its  training 
services. 

Services  may  be  delivered  through  combinations  of  manual  and 
automated  processes. 

This  term  has  a  special  meaning  in  the  CMMI  Product  Suite  besides  its 
common  standard  English  meaning. 
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service  agreement 


service  catalog 


service  incident 


service  level 


A  binding,  written  record  of  a  promised  exchange  of  value 
between  a  service  provider  and  a  customer.  (See  also 
“customer.”) 

Service  agreements  can  be  fully  negotiable,  partially  negotiable,  or  non- 
negotlable,  and  they  can  be  drafted  either  by  the  service  provider,  the 
customer,  or  both,  depending  on  the  situation. 

A  “promised  exchange  of  value”  means  a  joint  recognition  and 
acceptance  of  what  each  party  will  provide  to  the  other  to  satisfy  the 
agreement.  Typically,  the  customer  provides  payment  in  return  for 
delivered  services,  but  other  arrangements  are  possible. 

A  “written”  record  need  not  be  contained  in  a  single  document  or  other 
artifact.  Alternatively,  it  may  be  extremely  brief  for  some  types  of  services 
(e.g.,  a  receipt  that  identifies  a  service,  its  price,  its  recipient). 

A  list  or  repository  of  standardized  service  definitions. 

Service  catalogs  can  include  varying  degrees  of  detail  about  available 
service  levels,  quality,  prices,  negotiable/tailorable  items,  and  terms  and 
conditions. 

A  service  catalog  need  not  be  contained  in  a  single  document  or  other 
artifact,  and  can  be  a  combination  of  items  that  provide  equivalent 
information  (such  as  web  pages  linked  to  a  database.)  Alternatively,  for 
some  services  an  effective  catalog  can  be  a  simple  printed  menu  of 
available  services  and  their  prices. 

Service  catalog  information  can  be  partitioned  into  distinct  subsets  to 
support  different  types  of  stakeholders  (e.g.,  customers,  end  users, 
provider  staff,  suppliers). 

An  indication  of  an  actual  or  potential  interference  with  a 
service. 

Service  incidents  can  occur  in  any  service  domain  because  customer  and 
end-user  complaints  are  types  of  incidents  and  even  the  simplest  of 
services  can  generate  complaints. 

The  word  “incident”  can  be  used  in  place  of  “service  incident”  for  brevity 
when  the  context  makes  the  meaning  clear. 

A  defined  magnitude,  degree,  or  quality  of  service  delivery 
performance.  (See  also  “service”  and  “service  level 
measure.”) 
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service  level 
agreement 


service  level 
measure 

service  line 


service  request 


service 

requirements 


A  service  agreement  that  specifies  delivered  services; 
service  measures;  levels  of  acceptable  and  unacceptable 
services;  and  expected  responsibilities,  liabilities,  and 
actions  of  both  the  provider  and  customer  in  anticipated 
situations.  (See  also  “measure,”  “service,”  and  “service 
agreement.”) 

A  service  level  agreement  Is  a  kind  of  service  agreement  that  documents 
the  details  Indicated  In  the  definition. 

The  use  of  the  term  “service  agreement”  always  Includes  “service  level 
agreement”  as  a  subcategory  and  the  former  may  be  used  In  place  of  the 
latter  for  brevity.  However,  “service  level  agreement”  is  the  preferred  term 
when  it  is  desired  to  emphasize  situations  in  which  distinct  levels  of 
acceptable  services  exist,  or  other  details  of  a  service  level  agreement 
are  likely  to  be  important  to  the  discussion. 

A  measure  of  service  delivery  performance  associated  with 
a  service  level.  (See  also  “measure”  and  “service  level.”) 

A  consolidated  and  standardized  set  of  services  and  service 
levels  that  satisfy  specific  needs  of  a  selected  market  or 
mission  area.  (See  also  “product  line”  and  “service  level.”) 

A  communication  from  a  customer  or  end  user  that  one  or 
more  specific  instances  of  service  delivery  are  desired.  (See 
also  “service  agreement.”) 

These  requests  are  made  within  the  context  of  a  service  agreement. 

In  cases  where  services  are  to  be  delivered  continuously  or  periodically, 
some  service  requests  may  be  explicitly  identified  in  the  service 
agreement  itself. 

In  other  cases,  service  requests  that  fall  within  the  scope  of  a  previously 
established  service  agreement  are  generated  over  time  by  customers  or 
end  users  as  their  needs  develop. 

The  complete  set  of  requirements  that  affect  service  delivery 
and  service  system  development.  (See  also  “service 
system.”) 

Service  requirements  include  both  technical  and  nontechnical 
requirements.  Technical  requirements  are  properties  of  the  service  to  be 
delivered  and  the  service  system  needed  to  enable  delivery.  Nontechnical 
requirements  may  include  additional  conditions,  provisions,  commitments, 
and  terms  identified  by  agreements,  and  regulations,  as  well  as  needed 
capabilities  and  conditions  derived  from  business  objectives. 
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service  system 


service  system 
component 


service  system 
consumable 


An  integrated  and  interdependent  combination  of 
component  resources  that  satisfies  service  requirements. 
(See  also  “service  system  component”  and  “service 
requirements.”) 

A  service  system  encompasses  everything  required  for  service  delivery, 
including  work  products,  processes,  facilities,  tools,  consumables,  and 
human  resources. 

Note  that  a  service  system  includes  the  people  necessary  to  perform  the 
service  system’s  processes.  In  contexts  where  end  users  perform  some 
processes  for  service  delivery  to  be  accomplished,  those  end  users  are 
also  part  of  the  service  system  (at  least  for  the  duration  of  those 
interactions). 

A  complex  service  system  may  be  divisible  into  multiple  distinct  delivery 
and  support  systems  or  subsystems.  While  these  divisions  and 
distinctions  may  be  significant  to  the  service  provider  organization,  they 
may  not  be  as  meaningful  to  other  stakeholders. 

A  resource  required  for  a  service  system  to  successfully 
deliver  services. 

Some  components  can  remain  owned  by  a  customer,  end  user,  or  third 
party  before  service  delivery  begins  and  after  service  delivery  ends.  (See 
also  “customer”  and  “end  user.”) 

Some  components  can  be  transient  resources  that  are  part  of  the  service 
system  for  a  limited  time  (e.g.,  items  that  are  under  repair  in  a 
maintenance  shop). 

Components  can  include  processes  and  people. 

The  word  “component”  can  be  used  in  place  of  “service  system 
component”  for  brevity  when  the  context  makes  the  meaning  clear. 

The  word  “infrastructure”  can  be  used  to  refer  collectively  to  service 
system  components  that  are  tangible  and  essentially  permanent. 
Depending  on  the  context  and  type  of  service,  infrastructure  can  include 
human  resources. 

A  service  system  component  that  ceases  to  be  available  or 
becomes  permanently  changed  by  its  use  during  the 
delivery  of  a  service. 

Fuel,  office  supplies,  and  disposable  containers  are  examples  of 
commonly  used  consumables.  Particular  types  of  services  can  have  their 
own  specialized  consumables  (e.g.,  a  health  care  service  may  require 
medications  or  blood  supplies). 

People  are  not  consumables,  but  their  labor  time  is  a  consumable. 
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shared  vision 


software 

engineering 


solicitation 


solicitation  package 


special  cause  of 
variation 


specific  goal 


specific  practice 


stable  process 


staged 

representation 


A  common  understanding  of  guiding  principles,  including 
mission,  objectives,  expected  behavior,  values,  and  final 
outcomes,  which  are  developed  and  used  by  a  project  or 
work  group. 

(1)  The  application  of  a  systematic,  disciplined,  quantifiable 
approach  to  the  development,  operation,  and  maintenance 
of  software.  (2)  The  study  of  approaches  as  in  (1 ).  (See  also 
“hardware  engineering,”  and  “systems  engineering.”) 

The  process  of  preparing  a  package  to  be  used  in  selecting 
a  supplier.  (See  also  “solicitation  package.”) 

A  collection  of  formal  documents  that  includes  a  description 
of  the  desired  form  of  response  from  a  potential  supplier,  the 
relevant  statement  of  work  for  the  supplier,  and  required 
provisions  in  the  supplier  agreement. 

A  cause  of  a  defect  that  is  specific  to  some  transient 
circumstance  and  is  not  an  inherent  part  of  a  process.  (See 
also  “common  cause  of  variation.”) 

A  required  model  component  that  describes  the  unique 
characteristics  that  must  be  present  to  satisfy  the  process 
area.  (See  also  “capability  level,”  “generic  goal,” 
“organization’s  business  objectives,”  and  “process  area.”) 

An  expected  model  component  that  is  considered  important 
in  achieving  the  associated  specific  goal.  (See  also  “process 
area”  and  “specific  goal.”) 

The  specific  practices  describe  the  activities  expected  to  result  in 
achievement  of  the  specific  goals  of  a  process  area. 

The  state  in  which  special  causes  of  process  variation  have 
been  removed  and  prevented  from  recurring  so  that  only 
common  causes  of  process  variation  of  the  process  remain. 
(See  also  “capable  process,”  “common  cause  of  variation,” 
“special  cause  of  variation,”  and  “standard  process.”) 

A  model  structure  wherein  attaining  the  goals  of  a  set  of 
process  areas  establishes  a  maturity  level;  each  level  builds 
a  foundation  for  subsequent  levels.  (See  also  “maturity 
level”  and  “process  area.”) 
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stakeholder 


standard  (noun) 


standard  process 


statement  of  work 

statistical  and  other 

quantitative 

techniques 


statistical  process 
control 


A  group  or  individual  that  is  affected  by  or  is  in  some  way 
accountable  for  the  outcome  of  an  undertaking.  (See  also 
“customer”  and  “relevant  stakeholder.”) 

Stakeholders  may  include  project  or  work  group  members,  suppliers, 
customers,  end  users,  and  others. 

This  term  has  a  special  meaning  in  the  CMMI  Product  Suite  besides  its 
common  standard  English  meaning. 

Formal  requirements  developed  and  used  to  prescribe 
consistent  approaches  to  acquisition,  development,  or 
service. 

Examples  of  standards  include  ISO/IEC  standards,  IEEE  standards,  and 
organizational  standards. 

An  operational  definition  of  the  basic  process  that  guides  the 
establishment  of  a  common  process  in  an  organization. 

A  standard  process  describes  the  fundamental  process  elements  that  are 
expected  to  be  incorporated  into  any  defined  process.  It  also  describes 
relationships  (e.g.,  ordering,  interfaces)  among  these  process  elements. 
(See  also  “defined  process.”) 

A  description  of  work  to  be  performed. 

Analytic  techniques  that  enable  accomplishing  an  activity  by 
quantifying  parameters  of  the  task  (e.g.,  inputs,  size,  effort, 
and  performance).  (See  also  “statistical  techniques”  and 
“quantitative  management.”) 

This  term  is  used  in  the  high  maturity  process  areas  where  the  use  of 
statistical  and  other  quantitative  techniques  to  improve  understanding  of 
project,  work,  and  organizational  processes  is  described. 

Examples  of  non-statistical  quantitative  techniques  include  trend  analysis, 
run  charts,  Pareto  analysis,  bar  charts,  radar  charts,  and  data  averaging. 

The  reason  for  using  the  compound  term  “statistical  and  other  quantitative 
techniques”  in  CMMI  is  to  acknowledge  that  while  statistical  techniques 
are  expected,  other  quantitative  techniques  can  also  be  used  effectively. 

Statistically  based  analysis  of  a  process  and  measures  of 
process  performance,  which  identify  common  and  special 
causes  of  variation  in  process  performance  and  maintain 
process  performance  within  limits.  (See  also  “common 
cause  of  variation,”  “special  cause  of  variation,”  and 
“statistical  techniques.”) 
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statistical 

techniques 

subpractice 

subprocess 

supplier 

supplier  agreement 

sustainment 

system  of  systems 


Techniques  adapted  from  the  field  of  mathematical  statistics 
used  for  activities  such  as  characterizing  process 
performance,  understanding  process  variation,  and 
predicting  outcomes. 

Examples  of  statistical  techniques  Include  sampling  techniques,  analysis 
of  variance,  chi-squared  tests,  and  process  control  charts. 

An  informative  model  component  that  provides  guidance  for 
interpreting  and  implementing  specific  or  generic  practices. 

Subpractices  may  be  worded  as  if  prescriptive,  but  they  are  actually 
meant  only  to  provide  ideas  that  can  be  useful  for  process  improvement. 

A  process  that  is  part  of  a  larger  process.  (See  also 
“process,”  “process  description,”  and  “process  element.”) 

A  subprocess  may  or  may  not  be  further  decomposed  into  more  granular 
subprocesses  or  process  elements.  The  terms  “process,”  “subprocess,” 
and  “process  element”  form  a  hierarchy  with  “process”  as  the  highest, 
most  general  term,  “subprocesses”  below  it,  and  “process  element”  as  the 
most  specific.  A  subprocess  can  also  be  called  a  process  element  if  it  is 
not  decomposed  into  further  subprocesses. 

(1)  An  entity  delivering  products  or  performing  services 
being  acquired.  (2)  An  individual,  partnership,  company, 
corporation,  association,  or  other  entity  having  an 
agreement  with  an  acquirer  for  the  design,  development, 
manufacture,  maintenance,  modification,  or  supply  of  items 
under  the  terms  of  an  agreement.  (See  also  “acquirer.”) 

A  documented  agreement  between  the  acquirer  and 
supplier.  (See  also  “supplier.”) 

Supplier  agreements  are  also  known  as  contracts,  licenses,  and 
memoranda  of  agreement. 

The  processes  used  to  ensure  that  a  product  or  service 
remains  operational. 

A  set  or  arrangement  of  systems  that  results  when 
independent  and  useful  systems  are  integrated  into  a  large 
system  that  delivers  unique  capabilities. 
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systems 

engineering 


tailoring 


tailoring  guidelines 


target  profile 


target  staging 


The  interdisciplinary  approach  governing  the  total  technical 
and  managerial  effort  required  to  transform  a  set  of 
customer  needs,  expectations,  and  constraints  into  a 
solution  and  to  support  that  solution  throughout  its  life.  (See 
also  “hardware  engineering”  and  “software  engineering.”) 

This  approach  includes  the  definition  of  technical  performance  measures, 
the  integration  of  engineering  specialties  toward  the  establishment  of  an 
architecture,  and  the  definition  of  supporting  lifecycle  processes  that 
balance  cost,  schedule,  and  performance  objectives. 

The  act  of  making,  altering,  or  adapting  something  for  a 
particular  end. 

For  example,  a  project  or  work  group  establishes  its  defined  process  by 
tailoring  from  the  organization’s  set  of  standard  processes  to  meet  its 
objectives,  constraints,  and  environment.  Likewise,  a  service  provider 
tailors  standard  services  for  a  particular  service  agreement. 

Organizational  guidelines  that  enable  projects,  work  groups, 
and  organizational  functions  to  appropriately  adapt  standard 
processes  for  their  use. 

The  organization’s  set  of  standard  processes  is  described  at  a  general 
level  that  may  not  be  directly  usable  to  perform  a  process. 

Tailoring  guidelines  aid  those  who  establish  the  defined  processes  for 
project  or  work  groups.  Tailoring  guidelines  cover  (1 )  selecting  a  standard 
process,  (2)  selecting  an  approved  lifecycle  model,  and  (3)  tailoring  the 
selected  standard  process  and  lifecycle  model  to  fit  project  or  work  group 
needs.  Tailoring  guidelines  describe  what  can  and  cannot  be  modified 
and  identify  process  components  that  are  candidates  for  modification. 

A  list  of  process  areas  and  their  corresponding  capability 
levels  that  represent  an  objective  for  process  improvement. 
(See  also  “achievement  profile”  and  “capability  level 
profile.”) 

Target  profiles  are  only  available  when  using  the  continuous 
representation. 

A  sequence  of  target  profiles  that  describes  the  path  of 
process  improvement  to  be  followed  by  the  organization. 
(See  also  “achievement  profile,”  “capability  level  profile,”  and 
“target  profile.”) 

Target  staging  is  only  available  when  using  the  continuous 
representation. 


464 


Glossary 


CMMI  for  Development,  Version  1.3 


team 


technical  data 
package 


A  group  of  people  with  complementary  skills  and  expertise 
who  work  together  to  accomplish  specified  objectives. 

A  team  establishes  and  maintains  a  process  that  identifies  roles, 
responsibilities,  and  interfaces;  is  sufficiently  precise  to  enable  the  team 
to  measure,  manage,  and  improve  their  work  performance;  and  enables 
the  team  to  make  and  defend  their  commitments. 

Collectively,  team  members  provide  skills  and  advocacy  appropriate  to  all 
aspects  of  their  work  (e.g.,  for  the  different  phases  of  a  work  product’s 
life)  and  are  responsible  for  accomplishing  the  specified  objectives. 

Not  every  project  or  work  group  member  must  belong  to  a  team  (e.g.,  a 
person  staffed  to  accomplish  a  task  that  is  largely  self-contained).  Thus,  a 
large  project  or  work  group  can  consist  of  many  teams  as  well  as  project 
staff  not  belonging  to  any  team.  A  smaller  project  or  work  group  can 
consist  of  only  a  single  team  (or  a  single  individual). 

A  collection  of  items  that  can  include  the  following  if  such 
information  is  appropriate  to  the  type  of  product  and  product 
component  (e.g.,  material  and  manufacturing  requirements 
may  not  be  useful  for  product  components  associated  with 
software  services  or  processes): 

•  Product  architecture  description 

•  Allocated  requirements 

•  Product  component  descriptions 

•  Product  related  lifecycle  process  descriptions  if  not 
described  as  separate  product  components 

•  Key  product  characteristics 

•  Required  physical  characteristics  and  constraints 

•  Interface  requirements 

•  Materials  requirements  (bills  of  material  and  material 
characteristics) 

•  Fabrication  and  manufacturing  requirements  (for  both 
the  original  equipment  manufacturer  and  field  support) 

•  Verification  criteria  used  to  ensure  requirements  have 
been  achieved 

•  Conditions  of  use  (environments)  and  operating/usage 
scenarios,  modes  and  states  for  operations,  support, 
training,  manufacturing,  disposal,  and  verifications 
throughout  the  life  of  the  product 

•  Rationale  for  decisions  and  characteristics  (e.g., 
requirements,  requirement  allocations,  design  choices) 
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technical 

performance 


technical 

performance 

measure 

technical 

requirements 

traceability 


trade  study 


training 


unit  testing 


validation 


verification 


Characteristic  of  a  process,  product,  or  service,  generally 
defined  by  a  functional  or  technical  requirement. 

Examples  of  technical  performance  types  include  estimating  accuracy, 
end-user  functions,  security  functions,  response  time,  component 
accuracy,  maximum  weight,  minimum  throughput,  allowable  range. 

Precisely  defined  technical  measure  of  a  requirement, 
capability,  or  some  combination  of  requirements  and 
capabilities.  (See  also  “measure.”) 

Properties  (i.e.,  attributes)  of  products  or  services  to  be 
acquired  or  developed. 

A  discernable  association  among  two  or  more  logical  entities 
such  as  requirements,  system  elements,  verifications,  or 
tasks.  (See  also  “bidirectional  traceability”  and 
“requirements  traceability.”) 

An  evaluation  of  alternatives,  based  on  criteria  and 
systematic  analysis,  to  select  the  best  alternative  for 
attaining  determined  objectives. 

Formal  and  informal  learning  options. 

These  learning  options  can  include  classroom  training,  informal 
mentoring,  web-based  training,  guided  self  study,  and  formalized  on-the- 
job  training  programs. 

The  learning  options  selected  for  each  situation  are  based  on  an 
assessment  of  the  need  for  training  and  the  performance  gap  to  be 
addressed. 

Testing  of  individual  hardware  or  software  units  or  groups  of 
related  units.  (See  also  “acceptance  testing.”) 

Confirmation  that  the  product  or  service,  as  provided  (or  as 
it  will  be  provided),  will  fulfill  its  intended  use. 

In  other  words,  validation  ensures  that  “you  built  the  right  thing.”  (See  also 
“verification.”) 

Confirmation  that  work  products  properly  reflect  the 
requirements  specified  for  them. 

In  other  words,  verification  ensures  that  “you  built  it  right.”  (See  also 
“validation.”) 
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version  control 


work  breakdown 
structure  (WBS) 

work  group 


work  plan 


work  product 


work  product  and 
task  attributes 


The  establishment  and  maintenance  of  baselines  and  the 
identification  of  changes  to  baselines  that  make  it  possible 
to  return  to  the  previous  baseline. 

In  some  contexts,  an  individual  work  product  may  have  its  own  baseline 
and  a  level  of  control  less  than  formal  configuration  control  may  be 
sufficient. 

An  arrangement  of  work  elements  and  their  relationship  to 
each  other  and  to  the  end  product  or  service. 

A  managed  set  of  people  and  other  assigned  resources  that 
delivers  one  or  more  products  or  services  to  a  customer  or 
end  user.  (See  also  “project.”) 

A  work  group  can  be  any  organizational  entity  with  a  defined  purpose, 
whether  or  not  that  entity  appears  on  an  organization  chart.  Work  groups 
can  appear  at  any  level  of  an  organization,  can  contain  other  work 
groups,  and  can  span  organizational  boundaries. 

A  work  group  together  with  its  work  can  be  considered  the  same  as  a 
project  if  it  has  an  intentionally  limited  lifetime. 

A  plan  of  activities  and  related  resource  allocations  for  a 
work  group. 

Work  planning  includes  estimating  the  attributes  of  work  products  and 
tasks,  determining  the  resources  needed,  negotiating  commitments, 
producing  a  schedule,  and  identifying  and  analyzing  risks.  Iterating 
through  these  activities  can  be  necessary  to  establish  the  work  plan. 

A  useful  result  of  a  process. 

This  result  can  include  files,  documents,  products,  parts  of  a  product, 
services,  process  descriptions,  specifications,  and  invoices.  A  key 
distinction  between  a  work  product  and  a  product  component  is  that  a 
work  product  is  not  necessarily  part  of  the  end  product.  (See  also 
“product”  and  “product  component.”) 

In  CMMI  models,  the  definition  of  “work  product”  includes  services, 
however,  the  phrase  “work  products  and  services”  is  sometimes  used  to 
emphasize  the  inclusion  of  services  in  the  discussion. 

Characteristics  of  products,  services,  and  tasks  used  to  help 
in  estimating  work.  These  characteristics  include  items  such 
as  size,  complexity,  weight,  form,  fit,  and  function.  They  are 
typically  used  as  one  input  to  deriving  other  resource 
estimates  (e.g.,  effort,  cost,  schedule). 
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work  startup 


When  a  set  of  interrelated  resources  for  a  work  group  is 
directed  to  develop  or  deliver  one  or  more  products  or 
services  for  a  customer  or  end  user.  (See  also  “work 
group.”) 
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